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
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#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
- The presShell id seems to be not very useful, so drop it.
- Be more explicit about the scrollId which is generally quite useful (I always
have a hard time remembering which number is the scrollId)
- Label the RCD node with "rcd" rather than a "1" vs "0"
Differential Revision: https://phabricator.services.mozilla.com/D93436
This rewrites a big chunk of the NotifyLayersUpdated code (most of the code that
deals with incoming scroll requests from the main-thread) to instead iterate
through the list of ScrollPositionUpdates on the metadata and apply them in
order. A bunch of the ApplyXXXUpdateFrom functions on FrameMetrics have their
innards deduplicated and boil down to a single line, which is then inlined, so
those functions get removed entirely.
Note that this rewrite doesn't yet handle all the possible types of
ScrollPositionUpdate instances, just the ones that the old code handled. In the
future this support will be fleshed out with tests to exercise the relevant
codepaths.
There is also a change to nsGfxScrollFrame which slightly modifies the semantics
of mApzScrollPos to handle the case where multiple relative scrolls happen in a
single transaction. As the implementation now requires multiple relative
ScrollPositionUpdates rather than a single "unified" relative scroll in the
FrameMetrics, we need to update mApzScrollPos for each relative
ScrollPositionUpdate we generate.
Differential Revision: https://phabricator.services.mozilla.com/D88744
Likewise for RepaintRequest, and direct usages of mScrollOffset
inside FrameMetrics.
The general idea is:
* APZ's copy of the FrameMetrics stores the visual scroll offset,
so calls to GetScrollOffset() on it are replaced with
GetVisualScrollOffset()
* The layer tree's copy of the frame metrics (and copies derived
from that like mLastContentPaintMetrics) currently stores the
layout scroll offset, so calls to GetScrollOffset() on those
are replaced with GetLayoutScrollOffset().
The latter changes are particularly important, as they enable us
to modify the layer tree's copy to store (a main thread snapshot
of) the visual offset in mScrollOffset in a future patch.
This patch intends no functional changes. In the cases where we
change GetScrollOffset() to GetLayoutScrollOffset(), mScrollOffset
and mLayoutViewport.TopLeft() should already be storing the same
thing.
The patch identifies a few usages as suspicious but leaves them
functionally unchanged for now.
A few problematic usages of GetScrollOffset() remain, which will
require other fixes to remove.
Differential Revision: https://phabricator.services.mozilla.com/D87159
This reduces the need for conditional logic, and clarifies the model that
AsyncPanZoomController::mFrameMetrics stores the up-to-date async-scrolled
versions of the visual and layout viewport offsets, while
mLastContentPaintMetrics stores the versions as of the last paint.
Differential Revision: https://phabricator.services.mozilla.com/D87154
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
StaticPrefs.h will be removed two commits from now, so update these comments.
The patch removes the comment above SetUsesContainerScrolling() because it's
wrong -- it did use static prefs when introduced by bug 1181832 but then
stopped using static prefs in bug 1470504 -- and makes it inlinable.
Differential Revision: https://phabricator.services.mozilla.com/D39133
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
Now scroll-snap-type property on body element doesn't affect scroll position
so that scrollTo-scrollBy-snaps.html is needed to be modified to specify
scroll-snap-type on html.
Differential Revision: https://phabricator.services.mozilla.com/D27987
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
The assertion is not serving much purpose. Now that container scrolling is
a Live pref, checking it on the compositor side is racy if the pref is
flipped, and on the content side it's clear from the code that it will
only be set to true if the pref is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D7339
--HG--
extra : rebase_source : 4ba80a40969aeac50f303e949472e51d05884fbd
extra : histedit_source : 54c1c0ac5d33a1523080f43ab10c2d01b545a3cc
