Support force-disabling APZ properly on Android
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox75 | --- | fixed |
People
(Reporter: botond, Assigned: botond)
References
Details
Attachments
(4 files)
The currently implementation of the "force-disable APZ" mechanism is to fall back to the main thread's scroll offset when deciding what scroll offset to use for composition.
This doesn't work on Android because the main thread's scroll offset is the layout viewport offset, and therefore this breaks pinch zooming.
I think what we need to do instead if use the main thread's view of the visual viewport offset at the time of the last paint.
Assignee | ||
Comment 1•4 years ago
|
||
Bug 1519285 would make fixing this easier (but it's not a hard dependency).
Assignee | ||
Comment 2•4 years ago
•
|
||
(In reply to Botond Ballo [:botond] [spotty responses until Feb 19] from comment #0)
I think what we need to do instead if use the main thread's view of the visual viewport offset at the time of the last paint.
I tried this, and it makes bug 1610960 better, but it's still not great; switching over from APZ enabled to APZ force-disabled still causes a jarring jump in the view as we jump from the async scroll offset to the main-thread's (visual) scroll offset. We may need to take some additional measures, like only having force-disablement take effect at the end of a gesture rather than in the middle of one.
Assignee | ||
Comment 3•4 years ago
|
||
Given that bug 1612983 is changing AccessibleCaret to perform force-disabling in fewer scenarios (and in particular, not the in the original STR in bug 1610960), I think what I have so far should be good enough for now.
Assignee | ||
Comment 4•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
As part of this change, IsApzForceDisabled() no longer affects async zoom.
This is deliberate, as we don't repaint at intermediate resolutions during
a pinch-zoom gesture, so the alternative (also the previous behaviour) is
that the view does not update until the conclusion of the pinch-zoom gesture,
which is arguably worse than any out-of-sync issues that force-disabling
aims to address.
Depends on D62090
Assignee | ||
Comment 6•4 years ago
|
||
APZ may want to know what the main thread's view of the visual viewport offset
was at the time of the last paint even if the main thread does not want APZ
to scroll to that visual viewport offset.
Depends on D62091
Assignee | ||
Comment 7•4 years ago
|
||
This ensures that even if APZ is force-disabled, the permanent offset between
the visual and layout viewports is preserved during rendering.
Depends on D62093
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
Patches are causing some gtest failures:
Assignee | ||
Comment 9•4 years ago
|
||
(In reply to Botond Ballo [:botond] [spotty responses until Feb 19] from comment #8)
Patches are causing some gtest failures:
Looks like this was just a test issue. This is looking better:
Comment 10•4 years ago
|
||
Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b0b9c7a4a1d5 Simplify a misleading calculation in AsyncPanZoomController::GetCurrentAsyncTransform(). r=tnikkel https://hg.mozilla.org/integration/autoland/rev/a18ca1103448 Move handling of IsApzForceDisabled() into the GetEffective*() functions where possible. r=tnikkel https://hg.mozilla.org/integration/autoland/rev/31a3f433f328 Have the main thread always populate FrameMetrics::mVisualViewportOffset. r=tnikkel https://hg.mozilla.org/integration/autoland/rev/fa22f9fce567 Use the main thread's visual viewport offset as the fallback scroll offset when APZ is force-disabled. r=tnikkel
Comment 11•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b0b9c7a4a1d5
https://hg.mozilla.org/mozilla-central/rev/a18ca1103448
https://hg.mozilla.org/mozilla-central/rev/31a3f433f328
https://hg.mozilla.org/mozilla-central/rev/fa22f9fce567
Description
•