This is a new implementation of mix-blend compositing that is meant to be more idiomatic to WR and efficient.
Previously, mix-blend mode was composed in the following way:
1. parent stacking context was forced to isolate
2. source picture is also isolated
3. when rendering the isolated context, the framebuffer is read upon reaching the source. Both the readback and the source are placed in the RT cache.
4. a mix-blend draw call is issued to read from those cache segments and blend on top of the backdrop
The new implementation works by using the picture cutting (intruduced for preserve-3D contexts earlier) and some bits of magic:
1. backdrop stacking context is isolated with a special composition mode that prevents it from actually rendeing unless the suorce stacking context is invisible.
2. source stacking context is isolated with mix-blend composition mode that has a pointer to the backdrop picture
3. the instance of the backdrop picture is placed as a peer of the source picture (not a child)
4. if the backdrop is invisible, the source is drawn as a simple blit
5. otherwise, it's a draw call that reads from the isolated backdrop and source textures
Note the differences:
- parent stacking context is not isolated, but backdrop is
- no framebuffer readback is involved
- the source and backdrop pictures are rendered in parallel in a pass, improving the batching
- we don't blend onto the backdrop while reading from the backdrop copy at the same time
- the depth of the render pass tree is reduced: previously the parent and the source were isolated, now the source and the backdrop, which are siblings
Differential Revision: https://phabricator.services.mozilla.com/D20608
--HG--
rename : gfx/wr/wrench/reftests/blend/multiply-2-ref.yaml => gfx/wr/wrench/reftests/blend/multiply-3-ref.yaml
rename : gfx/wr/wrench/reftests/blend/multiply-3.yaml => gfx/wr/wrench/reftests/blend/multiply-4.yaml
extra : moz-landing-system : lando
This is a new implementation of mix-blend compositing that is meant to be more idiomatic to WR and efficient.
Previously, mix-blend mode was composed in the following way:
1. parent stacking context was forced to isolate
2. source picture is also isolated
3. when rendering the isolated context, the framebuffer is read upon reaching the source. Both the readback and the source are placed in the RT cache.
4. a mix-blend draw call is issued to read from those cache segments and blend on top of the backdrop
The new implementation works by using the picture cutting (intruduced for preserve-3D contexts earlier) and some bits of magic:
1. backdrop stacking context is isolated with a special composition mode that prevents it from actually rendeing unless the suorce stacking context is invisible.
2. source stacking context is isolated with mix-blend composition mode that has a pointer to the backdrop picture
3. the instance of the backdrop picture is placed as a peer of the source picture (not a child)
4. if the backdrop is invisible, the source is drawn as a simple blit
5. otherwise, it's a draw call that reads from the isolated backdrop and source textures
Note the differences:
- parent stacking context is not isolated, but backdrop is
- no framebuffer readback is involved
- the source and backdrop pictures are rendered in parallel in a pass, improving the batching
- we don't blend onto the backdrop while reading from the backdrop copy at the same time
- the depth of the render pass tree is reduced: previously the parent and the source were isolated, now the source and the backdrop, which are siblings
Differential Revision: https://phabricator.services.mozilla.com/D20608
--HG--
rename : gfx/wr/wrench/reftests/blend/multiply-2-ref.yaml => gfx/wr/wrench/reftests/blend/multiply-3-ref.yaml
rename : gfx/wr/wrench/reftests/blend/multiply-3.yaml => gfx/wr/wrench/reftests/blend/multiply-4.yaml
extra : moz-landing-system : lando
The tiling origin is computed withing image::tiles instead of being provided to the function.
In addition, the image rect in device space is exposed as function parameter.
In a followup, callers will have to determine the correct image rect using the blob image's visible area.
Differential Revision: https://phabricator.services.mozilla.com/D20175
--HG--
extra : moz-landing-system : lando
This bug occurs under the following conditions:
- The clip chain instance has multiple clip items.
- The first item in the clip chain is a clip rectangle, with:
- ClipMode::Clip
- Is in the same coordinate system as the primitive.
In this case, the code would skip adding the clip rect to the
mask (due to the same coord system). However, the logic that
determines whether to render subsequent masks with blend disabled
or multiplicative blend was only considering the index of the
clip item in the clip chain. In this case, these masks would
get added to the blend enabled batches, but the first clip mask
which would have written the initial mask values was skipped.
The end result was that the subsequent clip masks would be
blending with uninitialized render target contents from a previous
frame.
This patch changes the logic to track when the first clip mask
has actually been added to the batch, rather than relying on
the index. In this case, it means that the rounded rect mask
will get drawn in the blend disabled path, writing the correct
mask values without blending with the existing render target contents.
Differential Revision: https://phabricator.services.mozilla.com/D20590
--HG--
extra : moz-landing-system : lando
Without this patch, if we got a display item with the root clip id, we
would always clip that display item with the root clip of the enclosing
pipeline. However, this violates the documented semantics on
ClipId::root() which states that it effectively does no clipping.
Specifically, it could end up doing clipping if the display item was
part of a scrollframe that was scrolled such that the display item
extended beyond the enclosing pipeline.
This patch adds an extra argument to some of the flattening functions -
the flag is true when recursing the DL between a pipeline item and the
first stacking context that has a clip. For these items, the pipeline
clip is applied. Once inside the stacking context, the pipeline clip is
not applied.
Differential Revision: https://phabricator.services.mozilla.com/D20483
--HG--
extra : moz-landing-system : lando
On integrated GPUs, we are typically completely bound by memory
bandwidth and the number of pixels that get written / blended.
On real world pages, it's often the case that we end up with
clip tasks that are long in one dimension but not the other, due
to box-shadow edges, clip mask segments etc. When this occurs,
the logic that tries to get a small 'used_rect' to clear targets
to fails, since the union of those ends up being a very large
rect that covers (most of) the surface. This can cost a lot of
GPU time on some integrated chipsets.
Instead, it appears to be much faster to issue multiple clears,
one for each clip mask region, which is typically < 10% of the
surface we were clearing previously.
However, we can also restore an old optimization we used to have
which means we can skip clears altogether in the common case. The
first mask in a clip task will write to all the pixels in the mask,
so we can draw that with blending disabled (also a significant win
on integrated GPUs) and skip the clear in these cases. With this
functionality in place, the multiplicative blend mode is only
enabled for any clips other than the first in a mask (this is
quite a rare case - most clip tasks end up with a single mask).
On low end GPUs driving a 4k screen, I've measured GPU wins of up
to 5 ms/frame on some real world pages with this change.
Differential Revision: https://phabricator.services.mozilla.com/D19893
--HG--
extra : moz-landing-system : lando
By using WebRenderTextureHostWrapper for canvas, we could avoid triggering frame build on WebRender backend if WebRenderTextureHostWrapper is only change.
Differential Revision: https://phabricator.services.mozilla.com/D19896
--HG--
extra : moz-landing-system : lando
For some reason running these via cross-compiled wrench in Mozilla
automation produces a few pixels difference.
Differential Revision: https://phabricator.services.mozilla.com/D19368
--HG--
extra : source : f06721b552a819e4d2456f1c31d62c782d9a42cb
This introduces some env vars to allow running cross-compiled
binaries instead of running things on the builder. Additionally
the `cargo test --features "ipc"` check is modified to be `check`
instead since there are no actual tests being run by that command.
The only thing we lose is a rustdoc example check but we are
checking that on Linux anyway so doing it for Mac is redundant.
Differential Revision: https://phabricator.services.mozilla.com/D19367
--HG--
extra : source : ee403c79877e028c58fa9091dd360fe50a80af37
For some reason running these via cross-compiled wrench in Mozilla
automation produces a few pixels difference.
Differential Revision: https://phabricator.services.mozilla.com/D19368
--HG--
extra : moz-landing-system : lando
This introduces some env vars to allow running cross-compiled
binaries instead of running things on the builder. Additionally
the `cargo test --features "ipc"` check is modified to be `check`
instead since there are no actual tests being run by that command.
The only thing we lose is a rustdoc example check but we are
checking that on Linux anyway so doing it for Mac is redundant.
Differential Revision: https://phabricator.services.mozilla.com/D19367
--HG--
extra : moz-landing-system : lando
Manage the texture space for picture tiles separately inside the texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D19708
--HG--
extra : moz-landing-system : lando
This is a preparatory change that can be useful by itself:
- use match on EntryKind to allow safe expansion
- avoid code duplication in get()
- fix some comments
Differential Revision: https://phabricator.services.mozilla.com/D19674
--HG--
extra : moz-landing-system : lando
By retaining a global GPU cache handle for a dummy image block, we
can reduce the per-frame GPU cache uploads quite a bit, which
helps with compositor time.
Differential Revision: https://phabricator.services.mozilla.com/D19326
--HG--
extra : moz-landing-system : lando
Kartikaya Gupta
Dzmitry Malyshau
Razvan Maries
Coroiu Cristina
Nicolas Silva
Glenn Watson
Csoregi Natalia
sotaro
Noemi Erli
Dorel Luca
Bogdan Tara
Cosmin Sabou
Oana Pop Rus