The reason why the global ScrollGeneration::sCounter doesn't work for the APZ
case is the APZ sampler thread is per our top level browser window, so if
there are multiple browser windows at the same time, the sCounter will be muted
from different sampler threads.
Differential Revision: https://phabricator.services.mozilla.com/D133439
There is one thing to note in this patch that is a change: this patch changes the displayport that we log for test purposes from the critical display port to the display port.
This will only be different on android. If tests were checking this then they were broken because the critical display port has no significance. I did a quick survey of the tests I could find that used this. None of them seem like they really want the critical display port (given the new world where critical display port has no significance).
Depends on D127350
Differential Revision: https://phabricator.services.mozilla.com/D127351
In bug 1731929 we added this value, here we give it the value we want for child processes. I think the code comments should explain it.
Differential Revision: https://phabricator.services.mozilla.com/D126629
Because adding or removing a scrollbar can change without the resolution changing (in particular, when zooming in we can add scrollbars) and we don't want to detect that content has updated it's resolution and override our (apz) resolution in that case.
This happens when double tapping creates a scrollbar and the resulting repaint updates the apz resolution while the zoom animation is ongoing, messing it up for a frame.
Adding a field for frame metrics just for this is kind of gross, but it can go away when that todo is fixed in NotifyLayersUpdated.
Differential Revision: https://phabricator.services.mozilla.com/D113303
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Since bug 1650183, the value returned by this function is not
necessarily the composition size of the RCD-RSF, but may be
a smaller size suitable for bounding the composited size of
scroll frames in a given process.
Differential Revision: https://phabricator.services.mozilla.com/D104463
https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/gfx/layers/apz/src/AsyncPanZoomController.cpp#4866
scrollOffsetUpdated gets set to true if we get basically any scroll update, including a NewScrollFrame update that we create for every new scroll frame that just informs apzc the scroll offset is (0,0).
scrollOffsetUpdated being true means RequestContentRepaint gets called a little later. RequestContentRepaint causes a full display port to be set on the content. That is undesirable because we set zero margin display ports (via SetZeroMarginDisplayPortOnAsyncScrollableAncestors) and we don't want to expand them to full display ports.
This bug is to fix the regression caused by bug 1662013. Two other bugs also regressed this (bug 1627012 and bug 1667475), and we need to fix all of them to fix the problem. Bug 1687886 is filed for the regression from bug 1667475. Bug 1687926 is filed for the regression from bug 1627012.
Before https://hg.mozilla.org/integration/autoland/rev/b78646d59e32 we only set scrollOffsetUpdated to true if GetScrollOffsetUpdated() was set to true on the metrics, and it didn't get set to true for new scroll frames.
Differential Revision: https://phabricator.services.mozilla.com/D102587
https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/gfx/layers/apz/src/AsyncPanZoomController.cpp#5034
That RequestContentRepaint call gets executed every time isDefault is true (and ignoreVisualUpdate is false), ie whenever the azpc gets metrics for the first time. RequestContentRepaint causes a full display port to be set on the content. That is undesirable because we set zero margin display ports (via SetZeroMarginDisplayPortOnAsyncScrollableAncestors) and we don't want to expand them to full display ports
This bug is to fix the regression caused by bug 1627012. Two other bugs also regressed this (bug 1662013 and bug 1667475), and we need to fix all of them to fix the problem. Bug 1687886 is filed for the regression from bug 1667475. Bug 1687927 is filed for the regression from bug 1662013.
https://hg.mozilla.org/integration/autoland/rev/47328d6c1b40 made us request a repaint any time we have default metrics because we might get a new visual scroll offset, but if our visual scroll offset doesn't change we shouldn't need to do anything.
Differential Revision: https://phabricator.services.mozilla.com/D102586
https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/gfx/layers/apz/src/AsyncPanZoomController.cpp#4866
scrollOffsetUpdated gets set to true if we get basically any scroll update, including a NewScrollFrame update that we create for every new scroll frame that just informs apzc the scroll offset is (0,0).
scrollOffsetUpdated being true means RequestContentRepaint gets called a little later. RequestContentRepaint causes a full display port to be set on the content. That is undesirable because we set zero margin display ports (via SetZeroMarginDisplayPortOnAsyncScrollableAncestors) and we don't want to expand them to full display ports.
This bug is to fix the regression caused by bug 1662013. Two other bugs also regressed this (bug 1627012 and bug 1667475), and we need to fix all of them to fix the problem. Bug 1687886 is filed for the regression from bug 1667475. Bug 1687926 is filed for the regression from bug 1627012.
Before https://hg.mozilla.org/integration/autoland/rev/b78646d59e32 we only set scrollOffsetUpdated to true if GetScrollOffsetUpdated() was set to true on the metrics, and it didn't get set to true for new scroll frames.
Differential Revision: https://phabricator.services.mozilla.com/D102587
Also add AsyncPanZoomController::CanScrollDownwardsWithDynamicToolbar to tell
whether the root APZC is scrollable or there is room covered by the dynamic
toolbar so that we can tell GeckoView to move the dynamic toolbar in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D93914
Sometimes the main thread has multiple scroll position changes that could
individually be propagated to the compositor via paint-skip transactions.
Currently the code doesn't support that; on the second scroll position change
for a given scrollframe it bails out and falls back to a full transaction. This
patch allows this behaviour. The main change is just upgrade the data structure
to store an array of ScrollPositionUpdate instances instead of a single one,
and then plumbing that through. Care is taken to avoid unnecessary copies, by
moving the array where possible.
Differential Revision: https://phabricator.services.mozilla.com/D92446
It stopped being relative to mScrollOffset in bug 1519285, when that
patched change the value stored in mScrollOffset to be the visual
scroll offset even for the Layers copy of the metrics.
Depends on D91479
Differential Revision: https://phabricator.services.mozilla.com/D91480
The two existing uses were inconsistent in whether the margins
were relative to the visual viewport or the layout viewport.
We could fix this, but it turns out both uses are readily
refactored to not need the field, so this patch removes the
field.
Differential Revision: https://phabricator.services.mozilla.com/D91479
The only remaining use site only cares about whether or not the transaction
was a paint-skip transaction or not, so this patch adds a dedicated bool for
that, which unlocks some cleanup.
Depends on D90722
Differential Revision: https://phabricator.services.mozilla.com/D90723
Botond Ballo
Hiroyuki Ikezoe
Mike Conley
Timothy Nikkel
imoraru
Simon Giesecke
Andreea Pavel
Noemi Erli
Mihai Alexandru Michis
Kartikaya Gupta
Sylvestre Ledru