There is some ambiguity about whether ScheduleComposite will necessarily
trigger a composite all the way to nsWindow::DrawWindowUnderlay. Android
robocop tests assume it will, because they rely on DrawWindowOverlay
being called so they can take a screenshot and make progress,
but this is a very fragile assumption. They also rely on the entire
window being painted, which is also a fragile assumption.
This patch improves the situation by explicitly invalidating the current
window area when Android Java code needs to trigger a composite. This avoids
regressions from future patches in this series which make composition bail
out when there is nothing invalid.
The resulting setup is still a bit fragile for my taste but I'm not sure
what the ideal solution would be.
--HG--
extra : commitid : 3t3xqRdZs24
extra : rebase_source : b23749613663ca805484776ccf5e36b4ff00e3fe
The C++ GLContext wrapper doesn't know about the changes to the GL state that the
Java code does, so Java must be careful to restore the GL state to the way
it was. The ScopedGLState RAII code doesn't quite accomplish this because of caching
in the C++ GLContext wrapper, so we have to do this directly from Java code.
If a page is shorter than the screen, but taller than the screen with margins,
and has a fixed position top or bottom bar, it would be offset incorrectly
when scrolling downwards.
The bulk of this patch is fixing up pieces of code that infer the resolution
as the inverse of the scaling transform on the root layer. This used to be
how various bits of gfx code obtained the resolution, but now that we can set
the resolution on the actual presShell that contains the content, we can also
just read the resolution from the FrameMetrics directly.
The problematic scenario is when the page is exactly the height of the screen
(with dynamic toolbar not visible). In this case, the scrollable() function in
Axis.java returns false on the vertical axis, and so the JavaPanZoomController
never does any scrolling. This in turns means that the scrollBy code in
LayerMarginsAnimator never gets to run, so you can never drag the toolbar back
into being visible. The patch ensures that scrollable() returns true when some
or all of the margins are not visible, ensuring that in these scenarios the
user can still scroll the toolbar back onto the screen. This patch also adds
some comments/asserts to verify the new code is threadsafe.
This adds a notification callback to PanZoomTarget that the PanZoomController
can call to notify GeckoLayerClient that a subdocument is being scrolled. This
allows GeckoLayerClient to call LayerMarginsAnimator and alter the margins
accordingly, stopping a page from trapping the toolbar on/off the screen with
a screen-covering subframe.
Prior to this change, isBrowserContentDocumentDisplayed returned false
from the time that the isFirstPaint flag was set in layout to the time
that layout handed off the rendered document to the compositor. However
the way the function is used meant that it needs to return false until
the compositor actually composites the "first-paint" rendering,
otherwise other events can sneak in and run before the compositor. This
patch moves the tracking for the flag into GeckoLayerClient so that it
can be queried and modified synchronously from both the Gecko thread in
browser.js and the compositor thread in setFirstPaintViewport.
