Pre-cache the clip set -> node information as entries are pushed
on to the clip-tree builder stack.
This page is still not fast (it's a worst case for our current
code with box-shadow clips) but it's better than without this
patch (and we have plans to optimize the box-shadow case).
Differential Revision: https://phabricator.services.mozilla.com/D152956
We need to exclude shared clip roots if the hierarchy contains a
complex clip, as the shared clip applied by the tile cache during
compositing doesn't support complex clips.
Differential Revision: https://phabricator.services.mozilla.com/D152961
This patch refactors how clip chains are internally represented and used
during scene and frame building. The intent is to make clip processing
during frame building more efficient and consistent. Additionally, this
work enables follow ups to cache the result of clip-chain builds between
frame and scene builds.
These changes will significantly reduce the cost of the visibility pass
for the common case when not much content has changed. In this patch,
the public API for clipping remains (mostly) the same, in order to allow
landing and stabilising this work without major changes to Gecko. However,
a longer term goal is to make the public WR clip API more closely match
the internal representation, to reduce work done during scene building.
Clips on a primitive can be categorized into two buckets. The first are
local clips that are specific to the primitive and move with it. These
could essentially be considered part of the definition of the primitive
itself. The second are a hierarchy of clips that apply to one or more
items, and may move independently of the primitive(s) they clip. These
clips are things like scroll regions, stacking context clips, iframe
clip regions etc. On (real world) pages, the clip hierarchy is typically
quite shallow, with a small number of clips that are shared by a large
number of primitives.
Finding clips that are shared between primitives is both required (for
things such as determining which picture cache slice a primitive can
be assigned to, while applying the shared clips during composition), and
also a potential optimization (processing shared clips only once and
caching this clip state similar primitives).
The public clip-chain API has two complexities that make the above
difficult and time consuming for WR to determine. It was possible to
express a clipping hierarchy both via the legacy clip parenting path
(via `ClipId` definitions) and also via clip-chains (the `parent`
field of a `ClipChain`). Second, clip-chains themselves can define
an arbitrary number and ordering of clips. Clips can also implicitly
apply to primitives via parent stacking contexts and iframes, but must
sometimes be removed (when an intermediate surface is created) for
performance reasons.
The new internal representation provided by this patch introduces a
`ClipTree` structure which is built during scene building by accumulating
the set of clips that apply to a primitive from all explicit and implicit
sources, and grafting this on to the existing clip-tree structure.
This provides WR a simple way to determine which clips are shared between
primitive (by checking ancestry) and reduces the size of the internal
representation (by sharing clips where possible rather than duplicating).
Interning is still used to identify parts of the clip-tree that define
the same clipping state.
Specific changes in this patch:
* Remove legacy `ClipId` style parenting support (in conjunction with
previous patches)
* Remove the public API ability to specify the clip on a primitive via
`ClipId` (it must now be a clip-chain)
* Remove `combined_local_clip_rect` from `PrimitiveInstance`, reducing
the size of the structure significantly
* Introduce `ClipTree` used during frame building, which is created by
`ClipTreeBuilder` during scene building
* Separate out per-primitive clip concept (`ClipTreeLeaf`) from clipping
hierarchy (`ClipTreeNode`). In future, more elements will be moved to
the `ClipTreeLeaf` and the state of each `ClipTreeNode` will be cached)
* Simplify the logic to disable / remove clips during frame building that
are applied by parent surface(s)
* Port hit-testing to be based on `ClipTree` which is simpler, faster and
also resolves some edge case correctness bugs
* Use a simpler and faster method to find shared clips during picture
cache slice assignment of primitives
* Update wrench to use the public clip-chain API definition changes
This patch already introduces some real-world optimizations (for example,
`displaylist_mutate` becomes 6% faster overall), but mostly sets things
up for follow up patches to be able to cache clip-state between frames,
which should result in much larger wins.
Differential Revision: https://phabricator.services.mozilla.com/D151987
The patch from 1780321 relaxes shared surface allocation, by allowing
surfaces to be shared even if they exist for >1 pass. However, it has
a logic bug - _non shared_ surfaces that are created may then be
allocated from as a shared surface if the `free_after` matches. This
restores the `is_shared` logic that used to exist, which fixes this
edge case (and still allows the performance optimization on the cases
that were fixed by 1780321).
Differential Revision: https://phabricator.services.mozilla.com/D152707
A requirement of calling `get_relative_transform` is that the child
node is an ancestor of the reference node. To ensure this invariant
is met, we exclude non-ancestor scroll roots from consideration when
picking a scroll root for an atomic picture cache slice. However, this
can mean we select a non-optimal scroll root in some cases. But the
`get_relative_transform` constraint only applies if the spatial nodes
are in a different coordinate system - if we know that the scroll roots
are in the same coordinate system, we can always calculate the correct
relative transform, regardless of ancestry of the nodes. We can rely on
this to relax the condition here, which means we select a more appropriate
scroll root, resulting in much less invalidation and rasterization work
in these cases.
Differential Revision: https://phabricator.services.mozilla.com/D152236
In the presence of complex effects such as backdrop-filter, it's
possible that some picture cache tiles can be drawn in a different
pass to other picture cache tiles. If there are a large number of
child render tasks that are shared between tiles assigned to different
render passes, that may result in a large number of standalone render
target allocations, which can hurt performance and reduce batching
efficiency.
This patch allows shared surfaces to be used when they have a lifetime
that spans more than one pass. We track the `free_after` in the active
shared surface list, and only allocate tasks if they match the lifetime
of other tasks in that shared surface. Existing logic ensures that
surface is returned to the shared target pool only after the `free_after`
pass has occurred.
Differential Revision: https://phabricator.services.mozilla.com/D152235
This patch solves a performance problem and a semantic problem introduced
in Bug 1773109. That Bug changed the term tile cache 'backdrop' to mean
two distinct things:
1) An opaque region spanning the entire tiling area (the sole original
meaning).
2) An opaque region spanning the visible area.
Presently the code tries and fails to maintain both of those meanings in the
BackdropInfo structure. The problem arises when the tiling backdrop is one
color and the visible backdrop is a different color. There's only one color in
the structure! The existing code attempts to circumvent this by setting the
tile cache background_color for the tiling color, and that's slow. Even if it
wasn't slow, the opaque_rect is set for the tiling area instead of the actual
backdrop area, which is semantically confusing, and could lead to incorrect
draw on platforms that support native color layers.
This patch addresses these issues by adding a spanning_opaque_color to the
BackdropInfo structure, which will only be set when there is a backdrop that
covers the tiling area. That color can be used as a clear color for the slice
tiles, when set. This patch also adds a backdrop_rect which indicates the area
of the actual backdrop, if set. This backdrop_rect is used to size the native
color layers, if supported by the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D151942
There are some hit-test use cases that still rely on clip-chains
and invalid clip-chain handles inheriting from the root clip-id
for a pipeline.
This will become irrelevant once the clip-tree patches land next
week, but for now we can restore these to fix a regression going
out in a release.
Differential Revision: https://phabricator.services.mozilla.com/D151880
In webrender, external textures provide an override UV rect which is
not known until during rendering when the texture is actually
resolved. For brush shaders this value is automatically read from the
GPU cache, but for other shaders the UVs are passed as instance
attributes. Currently we use the overridden UV rect correctly for the
composite shader, but not the cs_scale shader.
On Android devices which do not support the
GL_OES_EGL_image_external_essl3 extension, the cs_scale shader is used
to render video in some cases. Because we were not handling the
texture's UV rect correctly, video was being rendered upside down on
some websites as a result.
This patch makes us manually override the scale shader's instance
data's source_rects when the source is an external
texture. Additionally, the cs_scale shader needs adapted to handle the
case where the UV rect is inverted.
Differential Revision: https://phabricator.services.mozilla.com/D151233
This is mostly just changing a small number of structs and function
params (most of the work has been done in previous patches).
Differential Revision: https://phabricator.services.mozilla.com/D150987
Also make the parent in ClipTemplate an Option, so that the
semantics are a bit clearer (follow up patches will remove this
parent field entirely).
Differential Revision: https://phabricator.services.mozilla.com/D150980
## Summary
Pass the fixed position element animation id through webrender, returning the
the animation id in the hit-test result if the element is a fixed position
element. This animation id then can be used to lookup the relevant Hit-Testing
Tree Node, which can be used to find the fixed (or sticky) position side bits.
## Motivation
Sticky content can be currently stuck to the root content or not, based on the
scroll position. As a result, when hit testing sticky content, APZ needs both
the sticky position side bits and additional information to determine if the
element is currently stuck to the root content. This is needed to fix the
hit-testing of sticky position content when a APZ transform is being applied,
such as overscroll and hiding the dynamic toolbar.
## Implementation
The information needed to determine if a element is currently stuck to the root
content and the fixed/sticky position side bits is already stored in the
hit-testing tree node. Any hit test result should have a corresponding
hit-testing tree node entry. When a hit-test result contains a animation id and
a hit-testing tree node is found, we can store a pointer to this node and use
this to check the fixed/sticky position side bits. Something similar is already
done for hit test results when a scrollbar is hit.
Differential Revision: https://phabricator.services.mozilla.com/D148648
This removes the last piece of code in wrench and gecko (there is
one more callsite in WR itself) that relies on the legacy clip
parenting code.
Differential Revision: https://phabricator.services.mozilla.com/D150694
Add a way to define an item-local clip-chain from a series of
clips. Port a couple of tests to use this instead of relying on
legacy clip-parenting (which we plan to remove soon).
Differential Revision: https://phabricator.services.mozilla.com/D150662
Some more work towards removing the use of legacy clipid parenting
in wrench test files. Add support for specifying the spatial id
without also setting the clip parent. Port some more wrench tests
to use spatial-id and/or clip-chain.
Differential Revision: https://phabricator.services.mozilla.com/D150528
Previously, a tile cache backdrop was an opaque color that was guaranteed
to cover the entire tile cache rect. This change makes it so that the
backdrop must only cover the visible area. For compositors that support
native color layers, this allows native color layers to be used more
often.
To make this work, the tile cache background color is updated whenever a
spanning backdrop is found. This ensures that tiles still clear to a
spanning color. The tile cache background is reset on each new scene, so
it won't carry a "stale" backdrop color.
Differential Revision: https://phabricator.services.mozilla.com/D150036
This patch ensures that the calculation for unused temporary buffers can
never overflow via subtraction. Instead of counting buffers as they are
taken from the vec, it just keeps track of how many are left. If a
previous frame has generated a lot of temporary buffers, this will detect
that the current frame didn't use them all.
Differential Revision: https://phabricator.services.mozilla.com/D150271
In future, it won't be possible to specify clip hierarchy by the
old ClipId identifier, so convert these ones to clip-chains now.
Differential Revision: https://phabricator.services.mozilla.com/D150342
We formerly published webrender to crates.io, but haven't done so in
several years. However, the in-tree version number still matches the
version published on crates.io, causing cargo-vet to flag that this is
something that should potentially be audited. We could silence that on
the cargo-vet side, but then if we ever starting publishing it again
we'd miss the nudge to certify the audit (which would be useful to
anyone consuming it). So bumping the versions to a not-yet-published
number is a good way to correctly articulate the situation.
Differential Revision: https://phabricator.services.mozilla.com/D150055
We formerly published webrender to crates.io, but haven't done so in
several years. However, the in-tree version number still matches the
version published on crates.io, causing cargo-vet to flag that this is
something that should potentially be audited. We could silence that on
the cargo-vet side, but then if we ever starting publishing it again
we'd miss the nudge to certify the audit (which would be useful to
anyone consuming it). So bumping the versions to a not-yet-published
number is a good way to correctly articulate the situation.
Differential Revision: https://phabricator.services.mozilla.com/D150055
We formerly published webrender to crates.io, but haven't done so in
several years. However, the in-tree version number still matches the
version published on crates.io, causing cargo-vet to flag that this is
something that should potentially be audited. We could silence that on
the cargo-vet side, but then if we ever starting publishing it again
we'd miss the nudge to certify the audit (which would be useful to
anyone consuming it). So bumping the versions to a not-yet-published
number is a good way to correctly articulate the situation.
Differential Revision: https://phabricator.services.mozilla.com/D150055
Previously, a tile cache backdrop was an opaque color that was guaranteed
to cover the entire tile cache rect. This change makes it so that the
backdrop must only cover the visible area. For compositors that support
native color layers, this allows native color layers to be used more
often.
To make this work, the tile cache background color is updated whenever a
spanning backdrop is found. This ensures that tiles still clear to a
spanning color. The tile cache background is reset on each new scene, so
it won't carry a "stale" backdrop color.
Differential Revision: https://phabricator.services.mozilla.com/D150036
