The AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--HG--
extra : moz-landing-system : lando
The AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--HG--
extra : moz-landing-system : lando
We've had a constant of 10 hard-coded there since early days.
Turning it into a configurable number allows us to easier tune it and
debug related issues.
Differential Revision: https://phabricator.services.mozilla.com/D32761
--HG--
extra : moz-landing-system : lando
This is the last big step towards consistent flattening of transformations.
It includes removing the old "project_to_2d" method from the utils.
Differential Revision: https://phabricator.services.mozilla.com/D32528
--HG--
extra : moz-landing-system : lando
During the visibility pass, the main clip chain instance for each
primitive is created. In the prim prepare pass, a clip chain instance
is generated for each segment (of primitives that are segmented).
This previously required maintaining the active clip chain stack
during both passes. However, this is not ideal for a number of
reasons: the code is somewhat complicated / error prone and the
segment clip chain building step does more work than required.
This patch changes the segment clip chain building code to set up
the active clip nodes based on the result of the initial clip
chain built for the overall primitive during the visibility pass.
This means that it's no longer necessary to maintain the active
clip chain stack during the prepare pass. This simplifies some
upcoming picture caching changes related to avoiding redundant
cache invalidations, which is the main motivation for the change.
Differential Revision: https://phabricator.services.mozilla.com/D32250
--HG--
extra : moz-landing-system : lando
This is a follow-up to https://phabricator.services.mozilla.com/D30600
Previously, I changed changed the space mapper logic to use the world transformations.
This was seemingly needed because we requrested the relation between primitives and
their clip nodes, which could be in unrelated spatial sub-trees.
However, I believe the change was a mistake, since for clips we should not even try
to get the relative mapping, and clipping is done in world space for these cases.
This change reverts that logic back. ~~Fingers crossed for the try to not show any
asserts firing up inside get_relative_transform.~~ Try is green 🎉
Differential Revision: https://phabricator.services.mozilla.com/D32382
--HG--
extra : moz-landing-system : lando
When pinch zooming webrender would re-rasterize glyphs for each tiny
difference in zoom level. This takes time in itself, but also causes
the texture cache to grow incredibly large, to the point where
resizing it to make room for more glyphs takes far too much time.
This patch avoids this by rounding the size at which glyphs are
rasterized whilst pinch zooming. To do this we add a FrameMsg which
APZ uses to tell webrender whether a spatial node is being pinch
zoomed. Then during frame building if a spatial node is being pinch
zoomed we override the raster space of its corresponding picture.
The chosen raster space is the current zoom level rounded up to the
nearest power of two, but not exceeding 8x. This seems to be a good
balance between quality and performance, though at high zoom levels
the cache still does grow very large due to the size of the glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D30213
--HG--
extra : moz-landing-system : lando
This patch contains two isolated changes related to upcoming picture
caching improvements. Specifically:
* Determine the blit reason for stacking contexts with clips
earlier, during scene building. This simplifies the code and
allows better detection of redundant stacking contexts.
* Centralize the code for pushing batch instances into a small
number of places. This will simplify the switch to adding
a single primitive to multiple batch lists, in the case of
dirty regions with different batchers.
Differential Revision: https://phabricator.services.mozilla.com/D31898
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
This makes DrawTarget and ReadTarget no longer require a borrow
on a texture. This was previously fine, but in the near future
WR will be rendering picture caching surfaces directly into
texture handles. To allow this, we need to remove the borrow check
requirement on DrawTarget for rustc.
Differential Revision: https://phabricator.services.mozilla.com/D31390
--HG--
extra : moz-landing-system : lando
ColorMatrix is rarely used but takes most space in the Filter enum.
This removes 44 bytes from the enum and all structs that embed it.
Differential Revision: https://phabricator.services.mozilla.com/D30910
--HG--
extra : source : 07bf88839e1c35e678d11790e149dfda7f00cf30
extra : intermediate-source : bf2c0752c25f339a1179377dbb312249426609de
To fix bug 1496540 it was made so that webrender clips border corner
segments so that they do not overlap with their opposing
edges. However, cases where opposing _edges_ both overlap with
eachother (rather than just a corner overlapping with an edge), the
corners are clipped too far and a gap is left in the middle.
Additionally, no clipping was added to the edge segments. So rather
than there be a gap there is an area that is painted twice, which is
apparent if the colour is semi-transparent.
This fixes these issues by identifying when opposing edges overlap and
calculating the midpoint, then clipping the edges and corners to that
midpoint instead.
Differential Revision: https://phabricator.services.mozilla.com/D30814
--HG--
extra : moz-landing-system : lando
The implementation of `Device::map_pbo_for_readback` on GLES (e.g., Windows
with ANGLE) was using the incorrect enumeration value when attempting to map
the buffer into memory.
Differential Revision: https://phabricator.services.mozilla.com/D31156
--HG--
extra : moz-landing-system : lando
* Store render task address per-instance rather than per-primitive, to allow adding a single primitive to multiple batches / render tasks.
* Store render task id inside alpha batch builder, since multiple batch builders will be passed in future.
* Add primitive visibility mask, storing a bit mask of which dirty regions a visible primitive intersects.
* Store RenderTaskAddress as a u16 in CPU and shader types.
* Add picture caching debug flag to wrench.
Differential Revision: https://phabricator.services.mozilla.com/D30854
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
When the clip chain generates the local clip rect for a primitive, it
can be empty. This violated the assumption that the visible rect will
never be empty, and so when we snap, it produces NaNs, which in turn,
violates other assumptions when converting between spaces, and hence the
crash.
Now we cull the primitive from the visible list if the local clip rect
is empty, or if the visible rect is empty.
Differential Revision: https://phabricator.services.mozilla.com/D30659
This change makes get_relative_transform() to no longer rely on any flattening done before in the pipeline.
This makes it correct is some of the cases we failed previously (see ini files removed).
It now does flattening on every flat coordinate system it passes through, and it's used for SpaceMapper.
The old RelativeTransform is now replaced with CoordinateSpaceMapping, which reduces the zoo of our types :)
Differential Revision: https://phabricator.services.mozilla.com/D30600
--HG--
extra : moz-landing-system : lando
In some cases, Gecko supplies a display item with an image clip
mask where the image itself does not exist in the resource cache.
In these cases, WR would skip requesting the image, but would
still try to fetch the image info during batching, causing a panic.
This patch skips adding clip items to the batching pass if the
image mask does not exist.
It also adds support to wrench for a crash test when the image
mask is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D30560
--HG--
extra : moz-landing-system : lando
This patch is scaffolding only - there shouldn't be any functional
changes as a result of these changes.
Differential Revision: https://phabricator.services.mozilla.com/D30330
--HG--
extra : moz-landing-system : lando
This moves creation of the render task graph to be slightly
earlier during frame building. Instead of creeating the render
tasks during prepare_prims, they are created during the
take_context call for pictures, before recursing into primitives.
This means that in future we can have a surface that targets
multiple render tasks (e.g. for multiple dirty regions), which
may create a different batch set for each region.
Differential Revision: https://phabricator.services.mozilla.com/D29994
--HG--
extra : moz-landing-system : lando
