Prevent trying to resize the buffer before the surface has been created. At
that point, we wouldn't know our maximum texture size, so we would've thrown a
RuntimeException.
Certain conditions would cause MultiTileLayer to incorrectly invalidate tiles,
or to reuse tiles incorrectly, which would cause checkerboarding (sometimes
permanent until a redraw occurs).
This addresses said issues:
- Removes manual invalidation on Document:Shown and Tab:Selected. This is
unnecessary, as the entire buffer will be invalidated when this happens
anyway. Sometimes Document:Shown happens *after* drawing has occurred,
which caused the entire screen to checkerboard incorrectly.
- Fix re-using off-screen tiles with the incorrect resolution. Tiles are stored
in a hash-map based on their unscaled position. As only tiles that intersect
with the update region in tile-space are invalidated, sometimes tiles that
were off-screen, but whose unscaled tile origin appears on-screen would be
incorrectly re-used. Fix this by checking that a tile's resolution matches the
current resolution before reusing it.
When rendering with an offset for MultiTileLayer, the tile origin was moved
to compensate, but this lead to there being a mismatch between Gecko's
displayport origin and the one recorded on the Java side.
Instead of altering the origin, allow setting a render offset on MultiTileLayer
instead, so the origin remains correct.
Instead of tying the tile-buffer in MultiTileLayer directly to the back-buffer
of the page, make sure rendering is always aligned to the tile grid and use
tiles on-demand. This makes better use of tiles when panning/zooming, and opens
up the route for further optimisations.
Instead of tying the tile-buffer in MultiTileLayer directly to the back-buffer
of the page, make sure rendering is always aligned to the tile grid and use
tiles on-demand. This makes better use of tiles when panning/zooming, and opens
up the route for further optimisations.
Instead of tying the tile-buffer in MultiTileLayer directly to the back-buffer
of the page, make sure rendering is always aligned to the tile grid and use
tiles on-demand. This makes better use of tiles when panning/zooming, and opens
up the route for further optimisations.
This uses MultiTileLayer instead of SingleTileLayer for devices that don't have
gralloc support. This has the advantage of reduced memory usage due to less
wastage from power-of-two textures, and can be a performance boost due to slow
sub-image updates on some devices.
The lock on the software buffer was not being respected when destroying the
surface on screen rotation, meaning we could destroy it while Gecko was still
drawing to it. This would certainly cause a crash on rotation under the right
conditions. The same situation also occurred in
GeckoSoftwareLayerClient.getBitmap().
We also waited until the next redraw when freeing the old texture associated
with the surface. This had the effect of temporarily increasing the memory
usage (generally by either 4.5 or 9 megabytes). If memory pressure is high,
this could also cause a crash, though it is far less likely than the above case.
We only ever want to respond to the latest viewport sent, separate the
viewport change into its own event and remove all but the latest in the queue
when processing events.
Since the geometryChanged function does nothing if the parameter passed
in is false, better to rename the function to be more indicative of
what it actually does, and remove all the resulting dead code.
This removes the hard-coded limit of 1024x2048 tile sizes, and allows for
arbitrary tile-sizes. It will still only allocate texture sizes in powers of
two, however. It replaces the tile size with a buffered-area size, which can be
re-allocated as the screen dimensions change.
This removes the hard-coded limit of 1024x2048 tile sizes, and allows for
arbitrary tile-sizes. It will still only allocate texture sizes in powers of
two, however. It replaces the tile size with a buffered-area size, which can be
re-allocated as the screen dimensions change.
If a scroll event comes in that changes the scroll coordinates
from those that were last set by user scrolling in Java, then
update the Java viewport with the new coordinates. Note that
this may occur in the middle of a draw, when Gecko already has
the transaction lock acquired on the tile buffer. Therefore we
need to delay the update until after the draw is complete.
Send an event to scroll to the focused input field when the
soft keyboard comes up. Ensure that this happens *after* the
viewport change event is sent to Gecko, so that Gecko actually
knows that browser viewport is smaller and doesn't just no-op
the scroll request.
Don't allow Gecko to set the viewport size because Java knows
this better. Allowing this behaviour could result in Bad Things(TM)
under certain race conditions such as described in bug 707285.
Missing pieces of the document resulted in pageWidth getting
assigned to NaN, which was serialized as null by JSON. This
resulted in an exception over in Java-land when deserialization
was attempted, and killed the viewport update entirely.
