If overscroll eats into a fixed margin, we need to apply the opposite
offset to the opposite side of the axis this occurred on. This has the effect
of fixed-position elements aligned to the bottom of the screen remaining
visible when at the top of the page.
This changes compositor creation so that we can specify an initial size and
makes sure the local variable in nsWindow reflects that the compositor starts
unpaused.
This fixes the conflicting animations when the dynamic toolbar is hiding/showing
and overscroll is snapping back simultaneously. This is by not clamping the
entire viewport on margin-setting, and by making sure that only calling
setFixedLayerMargins changes the fixed layer margins.
This uses the aforementioned method on nsIDOMWindowUtils to make sure layout's
idea of the fixed position margins matches those used in the compositor.
This causes the viewport size to differ, depending on the length of the page.
This has the effect of pages that size themselves to the size of the window
always having the toolbar visible, making sites like Google Maps more usable.
This makes it possible to scroll to the top of the page with the toolbar visible
in Firefox for Android. It also causes JavaScript scrolling to position 0 to
expose the toolbar.
Offset fixed layers in the compositor so that the toolbar in Firefox for Android
doesn't obscure them. This does not affect layout, so input on the elements in
said layers will appear broken.
This uses the aforementioned method on nsIDOMWindowUtils to make sure layout's
idea of the fixed position margins matches those used in the compositor.
This causes the viewport size to differ, depending on the length of the page.
This has the effect of pages that size themselves to the size of the window
always having the toolbar visible, making sites like Google Maps more usable.
This makes it possible to scroll to the top of the page with the toolbar visible
in Firefox for Android. It also causes JavaScript scrolling to position 0 to
expose the toolbar.
Offset fixed layers in the compositor so that the toolbar in Firefox for Android
doesn't obscure them. This does not affect layout, so input on the elements in
said layers will appear broken.
This uses the aforementioned method on nsIDOMWindowUtils to make sure layout's
idea of the fixed position margins matches those used in the compositor.
This causes the viewport size to differ, depending on the length of the page.
This has the effect of pages that size themselves to the size of the window
always having the toolbar visible, making sites like Google Maps more usable.
This makes it possible to scroll to the top of the page with the toolbar visible
in Firefox for Android. It also causes JavaScript scrolling to position 0 to
expose the toolbar.
Offset fixed layers in the compositor so that the toolbar in Firefox for Android
doesn't obscure them. This does not affect layout, so input on the elements in
said layers will appear broken.
This patch has a bunch of semi-independent changes that unfortunately
couldn't be split apart without introducing hacks to make stuff build
on the intermediate patches. The main changes are:
- Moving TouchEventHandler from LayerView to JavaPanZoomController
- Registering the touch interceptor on the LayerView rather than the
TouchEventHandler
- Moving the Tab:HasTouchListener handler from GeckoApp to JPZC
The net effect of all of this is that the TouchEventHandler is hidden
behind the PanZoomController interface and not accessible to GeckoApp
or GeckoAppShell.
Additionally, some of the JPZC methods were renamed from onXXX to
handleXXX to maintain the convention that onXXX methods are "interface"
methods (i.e. exposed to arbitrary other code) whereas handleXXX
methods are private/package and should only be called in very specific
ways.
In my haste, I forgot to address review comments before pushing. This
corrects indentation in PanningPerf.java, moves GetValidLowPrecisionRegion from
Layer to TiledLayerComposer and corrects checkerboard measurement when there
isn't a low precision buffer and when the display ports don't cover the screen.
In my haste, I forgot to address review comments before pushing. This
corrects indentation in PanningPerf.java, moves GetValidLowPrecisionRegion from
Layer to TiledLayerComposer and corrects checkerboard measurement when there
isn't a low precision buffer and when the display ports don't cover the screen.
Use DisplayPortCalculator.aboutToCheckerboard to determine if we're in risk of
checkerboarding while drawing tiles, and only then enable low precision
rendering. This makes sure that we don't spend time doing low precision
rendering when it isn't going to be of benefit (and thus decreases the
likelihood of the user seeing low precision tiles unnecessarily).
Frame-rate has an unpredictable effect on the results of robocop checkerboarding
tests. Instead of recording checkerboarding per frame, record it over time.
The checkerboard measurement depended on the displayport coverage of the
viewport, which was calculated in LayerRenderer. When using a critical
displayport, this value changes, but this was not being accounted for.
We have all the context we need for this Gecko-side, so move this code into
LayerManagerOGL::ComputeRenderIntegrity and account for displayport coverage
correctly.
Cancelling could happen at the wrong times due to using an out-of-date
resolution, or could not happen during low-res drawing due to not re-checking
the displayport age.
When doing a low precision update, send the display-port instead of the
critical display port so that more appropriate cancelling decisions can be
made.
When doing a low precision update, send the display-port instead of the
critical display port so that more appropriate cancelling decisions can be
made.
Sometimes the rounding error on display ports is over a pixel - in this case,
progressive updates may be cancelled incorrectly and cause drawing to be missed
until the next invalidation (assuming that isn't also incorrectly cancelled).
