This patch refactors how external surfaces are stored in the
CompositeState structure. This is primarily to simplify integration
with native compositor mode, but also simplifies the Draw compositor
path.
Previously, the ResolvedExternalSurface struct contained information
that was used to rasterize the external surface (YUV planes etc) and
also the information to composite it (device rect, clip rect, z_id).
Now, ResolvedExternalSurface contains just the information required
to rasterize the external surface, while the compositing information
is handled by adding the external surface as a regular tile. This
makes it possible to unify how external surfaces are drawn, via the
common draw_tile_list method.
Differential Revision: https://phabricator.services.mozilla.com/D65269
--HG--
extra : moz-landing-system : lando
Add support for a `fuzzy-range` keyword in reftest.list.
It is similar to `fuzzy` but it allows multiple pairs of
`max_difference, num_differences` numbers that introduce
multiple buckets of allowed differences.
For example, `fuzzy-range(5,100,20,10)` allows at most
100 pixels with a difference of at most 5, _plus_ an extra
10 pixels at most that have a difference more than 5 but
less than or equal to 20.
The total number of differing pixels allowed is thus 110,
but only if 100 of those differ by <= 5 and the remaining
10 by <= 20.
110 pixels with a difference <= 5 will still fail.
This is intentional to encourage tighter bounds in tests
where many pixels are slightly off and a few outliers are
off by a lot.
The number of parameters is arbitrary; longer lists can
get confusing so this change also introduces optional
support for writing `<=` in front of the max difference
and `*` in front of the max pixel count, eg.
`fuzzy-range(<=5,*100,<=20,*10)` (no spaces).
Any pixels that exceed the highest maximum will fail the
test, similar to `fuzzy`.
Steps tested:
1. the same tests fail in exactly the same way before and after;
2. reordered the `fuzzy` statements for raster_root_A/B/C to no longer
be sorted by max difference, and verified that the tests pass/fail
the same way;
(then sort them again which is easier to understand);
3. tests using the new feature still fail when the ref no longer matches
(deliberately broke the _ref version and verified test failed);
Differential Revision: https://phabricator.services.mozilla.com/D65247
--HG--
extra : moz-landing-system : lando
Ensure that the image keys and image generations for external
compositor surfaces are included in the composite descriptor,
which is used to determine if a composite is required or can
be skipped.
Differential Revision: https://phabricator.services.mozilla.com/D65216
--HG--
extra : moz-landing-system : lando
Rather than treating webrender::intern::UpdateList as a sequence of operations,
each of which might be an insertion or a removal, and using a side table to
supply extra data for insertions, it's simpler to segregate insertions and
removals into two separate vectors. This avoids the need for an enum whose
discriminant needs to be checked within the loop, and allows a few loops that
are only looking for one kind of operation to skip over the others entirely.
Ultimately, there should be no change in the order in which operations occur. In
practice, the old UpdateList always held a contiguous run of insertions,
followed by a run of removals (removals are consumed by apply_updates directly
after being generated by end_frame_and_get_pending_updates).
Differential Revision: https://phabricator.services.mozilla.com/D64444
--HG--
extra : moz-landing-system : lando
This patch improves the performance of compositor surfaces in
two ways:
(1) Ignore primitives behind the first compositor surface when
determining whether a tile needs to be moved to the overlay
(alpha) pass. This means WR only moves a tile to the alpha
pass when it has primitives that overlap with the compositor
surface bounding rect, and are ordered after that compositor
surface. In practice, this means most tiles are able to
remain in the fast (opaque) path. Typically, a small number
of tiles that contain overlay video controls are moved to the
alpha pass.
(2) Register the opaque compositor surfaces as potential occluders.
This allows tiles that are completely covered by a compositor
surface to be removed from the compositor visual tree, which
helps both the simple and native compositor modes.
Between them, these optimizations typically mean that when watching
video in full-screen, nothing is composited except the video surface
itself, and some small region(s) where video overlay controls are
currently active.
Differential Revision: https://phabricator.services.mozilla.com/D64909
--HG--
extra : moz-landing-system : lando
The appveyor.yml change bumps it for windows. The macOS worker has the
rust version bumped out-of-band and the change to .taskcluster.yml just
updates the documentation.
Differential Revision: https://phabricator.services.mozilla.com/D64945
--HG--
extra : moz-landing-system : lando
A previous patch in this series introduced overlay tiles. However,
now that native surfaces exist for for the opaque and alpha tiles
within a slice, we can remove the overlay tiles array and add
these special tiles to the alpha surface.
Differential Revision: https://phabricator.services.mozilla.com/D64899
--HG--
extra : moz-landing-system : lando
This patch fixes an oversight in part 5 of this patch series that
could result in an incorrect UV rect being used for an external
texture that uses a custom UV rect.
When the texture is an external texture, the UV rect is not known when
the external surface descriptor is created, because external textures
are not resolved until the lock() callback is invoked at the start of
the frame render. To handle this, query the texture resolver for the
UV rect if it's an external texture, otherwise use the default UV rect.
Differential Revision: https://phabricator.services.mozilla.com/D64687
--HG--
extra : moz-landing-system : lando
Previously, a native compositor surface was considered to be
completely opaque, or completely translucent. This is due to
a limitation in how alpha is handled in the DirectComposition
API level.
With this patch, each picture cache slice maintains both an
opaque and translucent native surface handle. Tiles are assigned
to one of those surfaces based on their current opacity.
This is a performance optimization in some cases, since:
- Even if part of a cache is translucent, opaque tiles can
still participate in occlusion at the compositor level.
- If a tile is changing from opaque to translucent, it now
invalidates only that tile, rather than the entire surface.
The primary benefit of this patch is that it allows compositor
surfaces to be drawn sliced in between the opaque surface and
any overlay / alpha tiles.
Differential Revision: https://phabricator.services.mozilla.com/D64495
--HG--
extra : moz-landing-system : lando
This was causing one of the large drop-shadow wrench reftests to timeout.
This is only a partial fix, as we should be checking the scale factors earlier on when sanitizing the
filter input. This will ensure we match what the non-WR backend is doing and will prevent overinflation.
Differential Revision: https://phabricator.services.mozilla.com/D64197
--HG--
extra : moz-landing-system : lando
This patch adds support for YUV images to be promoted to compositor
surfaces when using the simple (draw) compositor mode. A follow up
to this will extend support to native compositor implementations.
We rely on only promoting compositor surfaces that are opaque
primitives. With this assumption, the tile(s) that intersect the
compositor surface get a 'cutout' in the location where the
compositor surface exists, allowing that tile to be drawn as
an overlay after the compositor surface.
Tiles are only drawn in overlay mode if there is content that
exists on top of the compositor surface. Otherwise, we can draw
the tiles in the normal fast path before the compositor surface
is drawn.
The patch also introduces a new subpixel AA mode, which allows
subpixel rendering to be enabled conditionally as long as the
text run does not intersect some number of excluded rectangle
regions. In this way, subpixel text remains on most of the page,
but is disabled for elements that are drawn into transparent
regions of the tile where the compositor surface exists.
This allows video playback to be composited directly into the
framebuffer, without invalidation of content tiles, which can
save a significant amount of battery power and improve performance.
Differential Revision: https://phabricator.services.mozilla.com/D63816
--HG--
extra : moz-landing-system : lando
Previously we only saved shaders to disk on the tenth frame, meaning
shaders compiled afterwards would not be cached and would need to be
recompiled in future runs of the application. This change makes it so
that we cache shaders to disk regardless of which frame they are
compiled in.
We continue to treat only the shaders used within the first ten frames
as the "startup shaders", meaning only those ones will be loaded on
next startup. Caching as many other shaders as possible is still
beneficial, however, as they are loaded on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D62748
--HG--
extra : moz-landing-system : lando
This patch folds the raster scale and device pixel scale effects into
the font transform, instead of the font size itself. This helps minimize
the quantization effect given the font size is stored as an Au
(resolution of 1/60) instead of an f32, and the shader does not
replicate that effect.
Differential Revision: https://phabricator.services.mozilla.com/D63641
--HG--
extra : moz-landing-system : lando
Move the UV writing function into the shared yuv.glsl include so
that the YUV compositing shader will be able to access it.
Differential Revision: https://phabricator.services.mozilla.com/D63815
--HG--
extra : moz-landing-system : lando
