With this change, `has-scroll-linked-effect` flag won't persist so that we can
avoid choosing either the one-frame delayed scroll offset or the latest scroll
offset in cases where there's no longer effective scroll linked effect. It will
mitigate scroll jittering.
Differential Revision: https://phabricator.services.mozilla.com/D141457
With this change, `has-scroll-linked-effect` flag won't persist so that we can
avoid choosing either the one-frame delayed scroll offset or the latest scroll
offset in cases where there's no longer effective scroll linked effect. It will
mitigate scroll jittering.
Differential Revision: https://phabricator.services.mozilla.com/D141457
Add an interface (and update Gecko to provide) a stable unique
identifier for each spatial node that is consistent across
display lists.
Although this patch doesn't _do_ anything useful with this yet,
we'll use this in future to allow interning, persisting and caching
a lot more information related to primitives and clips.
For now, it just asserts that the calling code never supplies a
duplicate unique identifier - which will be useful to have running
in nightly for a couple of weeks before starting to make use of
these identifiers.
Differential Revision: https://phabricator.services.mozilla.com/D123177
Add an interface (and update Gecko to provide) a stable unique
identifier for each spatial node that is consistent across
display lists.
Although this patch doesn't _do_ anything useful with this yet,
we'll use this in future to allow interning, persisting and caching
a lot more information related to primitives and clips.
For now, it just asserts that the calling code never supplies a
duplicate unique identifier - which will be useful to have running
in nightly for a couple of weeks before starting to make use of
these identifiers.
Differential Revision: https://phabricator.services.mozilla.com/D123177
This was used when defining scroll layers and also backdrop-filter.
Removing it from the scroll layer API allows removal of the implicit
clip rect that a scroll node previously created (Gecko doesn't use
this). To maintain compatibility with wrench tests, add a flag that
allows a test to specify a clip rect should be created for the scroll
layer (we should remove this from wrench in future and port the tests
to create explicit clip rects as required).
The usage of backdrop-filter was the only remaining place this type
was used, so it's now ported to use the clip-chain API.
This simplifies the scroll layer API and removes an extra clip rect
from each scroll layer instance, as a small performance improvement.
Differential Revision: https://phabricator.services.mozilla.com/D119938
This removes the last use of DefineClip from Gecko, which will
allow removing and simplifying a lot of the clip handing code
during scene building in WR.
Differential Revision: https://phabricator.services.mozilla.com/D118121
Ensure that the external scroll offset is rounded from app units
into whole device pixels. This means that the primitive content id
matches in cases with non-round device pixel ratios, avoiding
unnecessary invalidations in these cases.
Differential Revision: https://phabricator.services.mozilla.com/D93175
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
The displayport clip that is applied to sticky items from the enclosing
scrollframe can cause sticky items to checkerboard even when they might
reasonably be left visible. This is because the displayport clip moves as
the enclosing scrollframe is scrolled, but sticky items may remain fixed
during such scrolling. The displayport clip can therefore clip out sticky
items even if they are "stuck" and should be user-visible.
This patch sets a flag to identify when a sticky item is being clipped by
the displayport clip, and ensures that it doesn't actually get clipped. In
the case where other clips are being applied to the sticky item, we leave the
clips unaffected. This allows for other enclosing elements to clip the sticky
item as before.
Differential Revision: https://phabricator.services.mozilla.com/D68582
Webrender positions sticky items relative to the viewport rect set on
their ancestor scroll frame, which it expects to be in local
space. The viewport should be set to what gecko calls the scroll
frame's "scroll port" (relative to its reference frame).
Previously we were setting this to be `composition bounds /
resolution`, which gives the correct results at the initial zoom
level, but causes sticky items to jump around when the zoom
changes. This occurs because the composition bounds of the RCD-RSF do
not change as the zoom changes, and instead remain equal to the
widget's size.
The layout viewport remains at the correct size when zoomed, but
unfortunately doesn't have the correct origin. And FrameMetrics does
not provide the constant "initial zoom" value we require to obtain the
desired viewport rect from the composition bounds. To fix this we
therefore must query the scroll port and offset directly from the
scrollable frame, meaning the value remains correct even as the zoom
changes.
Differential Revision: https://phabricator.services.mozilla.com/D60970
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
The clip rect is derived from the composition bounds, which is in units that
are outside the resolution, but it's applied to the ScrollFrame item which is
inside the resolution.
Differential Revision: https://phabricator.services.mozilla.com/D37939
A spatial id of 0 refers to the root reference frame on the WR side, but
we shouldn't be using that on the Gecko side at all. Due to the
early-exit codepath in ClipManager we were actually sending some display
items with this spatial id over to WebRender. Although this doesn't
appear to cause any user-visible problems it seems wrong and can confuse
debugging other issues.
Differential Revision: https://phabricator.services.mozilla.com/D25296
It turns out that setting the parent link on a clip chain is no longer
needed (and probably hasn't been since WR started applying a stacking
context's clip to the SC's contents). In fact it can produce incorrect
behaviour in some cases, because it doesn't match the semantics of
Gecko's clip chains. This removes the parent link on the Gecko side and
adds a test for this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18101
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
