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
cargo fix works by building under a specific config, so we can't hit both
sides of a mutually exclusive pair of cfgs, such as cfg(target_os) or
when cfg(feature) and cfg(not(feature)) both exist in the codebase.
Differential Revision: https://phabricator.services.mozilla.com/D29568
--HG--
extra : moz-landing-system : lando
Notably `extern crate foo as bar` is no longer supported
(must do it in Cargo.toml). Also stopped using euclid through webrender_api,
because it produces worse results in 2018.
Differential Revision: https://phabricator.services.mozilla.com/D29566
--HG--
extra : moz-landing-system : lando
There's two ways we could get around this. We could add a path
around the prepared_for_frames assertion in GpuCache::end_frame,
or we can do this, and leave the TODO explicit with the
assertion. I took the latter approach because we can clear
the GpuCache / TextureCache through other routes than frame
building anyway, so we could hit this failure path before
any of the patches in this bug landed.
Differential Revision: https://phabricator.services.mozilla.com/D29884
--HG--
extra : moz-landing-system : lando
These aren't great names - I couldn't come up with better though.
We lose the symmetry of before/after but this clarifies a little
bit what they are doing.
Differential Revision: https://phabricator.services.mozilla.com/D29877
--HG--
extra : moz-landing-system : lando
If we run a GpuCache clear and do not update all documents, we run into
situations where the stale documents try to access things in the gpu
cache and just show random garbage. The solution is similar to what we
do for TextureCache, so I am just duplicating those signatures and providing
helpers in RenderBackend to access both together.
Differential Revision: https://phabricator.services.mozilla.com/D29860
--HG--
extra : moz-landing-system : lando
Due to the render task ping-pong target allocation scheme, we need to ensure:
- that tasks only read from tasks that are an odd number of passes apart,
- that render task content is kept valid long enough for all of the dependent tasks.
The former is solved in this patch through blit tasks, the latter by marking tasks for saving as needed.
Differential Revision: https://phabricator.services.mozilla.com/D29800
--HG--
extra : moz-landing-system : lando
If a document has an empty rect for whatever reason (in the case observed, this was
due to running a full screen video in the content document, which occludes the
chrome document), then we still want to ensure that we build a frame if the
texture cache has performed a clear, as otherwise we may try to access stale
items from the texture resolver in render_impl.
Differential Revision: https://phabricator.services.mozilla.com/D29848
--HG--
extra : moz-landing-system : lando
Historically we calculated the snapping offsets in the GPU shaders.
Because this information is always needed on the CPU side, we now just
pass the values into the shader instead of recalculating again. This
ensures we will use the same set of values consistently and makes it
easier to adjust how we snap in the future.
This patch should have no functional change on the output of WebRender
itself.
Differential Revision: https://phabricator.services.mozilla.com/D28883
We currently do most snapping on the GPU in the shader. However the
picture's local rect needs to take into account the snapping done there,
so we need to calculate this earlier in the pipeline. Instead of using
the clipped primitive local rects to create the picture's own local
rect, we now snap the child local rects first. If no snapping is
required, there should be no functional change. If snapping is required,
there should be fewer visual distortions caused by an inaccurate picture
local rect.
Differential Revision: https://phabricator.services.mozilla.com/D28882
We currently calculate a picture's local rect when we are doing the
first picture traversal. It was composed of the union of the clipped
local rects of its children. However the true local rect of a picture is
the union of the snapped clipped local rects of its children. The
snapping is done in device space, but we won't know the exact transform
until we establish the raster roots, which is based on the picture's
local rect.
As such, we create an estimated local rect which is how we currently
calculate the local rect. Then once the raster roots have been selected,
we recalculate the local rect of the picture based on its children
during update visibility.
This patch should have not contain any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D28881
This builds on earlier patches to move all remaining resource requests
to occur during the visibility pass, and change the block on glyph
rasterization to occur after the visibility pass.
This allows batch generation to occur during the prepare_prims pass,
which is useful for generating a batch set per-dirty-region, while
only doing a single pass of the picture / primitive tree.
Differential Revision: https://phabricator.services.mozilla.com/D29584
--HG--
extra : moz-landing-system : lando
Introduce a new texture allocation operation "reset", which acts like a "realloc" but without the contents preserved.
Use it for the picture texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D29539
--HG--
extra : moz-landing-system : lando
In trying to diagnose bug 1538540, I'm hitting my limits as far as
simply staring at the code and trying to work out possible ways to
hit the crash goes. This assertion will split the search space into
clear-related causes and non-clear-related causes to narrow things
down.
Differential Revision: https://phabricator.services.mozilla.com/D29420
--HG--
extra : moz-landing-system : lando
Use natively supported mix-blend modes, where appropriate. Disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D26350
--HG--
extra : moz-landing-system : lando
This patch changes glyph requests in the resource cache to occur
as soon as a text run is found to be visible, rather than during
the prepare_prims pass.
This has two major benefits:
- (with other patches) will allow some batching code to run
during the prepare_prims pass.
- allows glyph raster worker threads to start earlier in the
frame, which may lead to less time blocking on the workers.
Differential Revision: https://phabricator.services.mozilla.com/D29458
--HG--
extra : moz-landing-system : lando
This is a first step towards allowing (some) batching work to be
done during prepare_prims pass rather than render pass building.
This is prep work related to output different batch lists for a given
picture (e.g. a different batch list per dirty region), rather than
replaying the same batch list.
Differential Revision: https://phabricator.services.mozilla.com/D29445
--HG--
extra : moz-landing-system : lando
In addition, batch together render tasks for the cached render tasks.
Differential Revision: https://phabricator.services.mozilla.com/D23839
--HG--
extra : source : 1b80e184b0bd6324ea62d1e38b2061da2b96a867
In trying to diagnose bug 1538540, I'm hitting my limits as far as
simply staring at the code and trying to work out possible ways to
hit the crash goes. This assertion will split the search space into
clear-related causes and non-clear-related causes to narrow things
down.
Differential Revision: https://phabricator.services.mozilla.com/D29420
--HG--
extra : moz-landing-system : lando
The Rgba8 enum value is redundant with the Standard(ImageFormat::RGBA8) value,
this patch collapses the former into the latter. Which then makes the entire
ReadPixelsFormat redundant, so we can get rid of it completely.
Differential Revision: https://phabricator.services.mozilla.com/D29059
--HG--
extra : moz-landing-system : lando
This changes our backface visibility semantics to a slightly more complex rule,
as described by Matt (and reinterpret by me in the context of WR) in bug 1525641 during our work week.
We are now propagating is_backface_visible to pictures and evaluate it in the context of
the local transform for a picture if it's outside of preserve-3d context.
We also refactor get_relative_transform() a bit.
Note: this fixes all of the existing backface-visibility bugs: 1525641, 1546110, 1546818
It also passes the Wrench tests, but the try push is still pending for surprises.
Differential Revision: https://phabricator.services.mozilla.com/D29009
--HG--
rename : gfx/wr/wrench/reftests/backface/backface-leaf.yaml => gfx/wr/wrench/reftests/backface/backface-3d-leaf.yaml
extra : moz-landing-system : lando
This adds a RendererOption flag to control whether the debug server is
enabled. This allows the debug server feature to be built without
enabling the feature by default; it can then be enabled on a
per-renderer basis via the RendererOption.
Differential Revision: https://phabricator.services.mozilla.com/D28352
--HG--
extra : moz-landing-system : lando
The debugger in WebRender uses the image crate to generate PNGs, and so
it only really needs the png codec feature from the image crate.
Differential Revision: https://phabricator.services.mozilla.com/D28351
--HG--
extra : moz-landing-system : lando
The gist of the problem I introduced with the framebuffer coordinate system is that we provided the window rect (effectively) twice:
1. when computing the document rectangle (and Y-inverting it)
2. when rendering
If between these points the window got resized (during scene building), we end up with our document aligned to bottom left corner.
The user expects content to still be aligned to the top left, so that's what is visible as a bug.
The change here switched scene building to only care about device coordinate space, restraining the framebuffer coordinates to be mostly
an implementation detail of the renderer/device (the way it was originally meant to be, when introduced). This way the current window size
is only considered once during rendering.
Differential Revision: https://phabricator.services.mozilla.com/D28731
--HG--
extra : moz-landing-system : lando
This adds a RendererOption flag to control whether the debug server is
enabled. This allows the debug server feature to be built without
enabling the feature by default; it can then be enabled on a
per-renderer basis via the RendererOption.
Differential Revision: https://phabricator.services.mozilla.com/D28352
--HG--
extra : moz-landing-system : lando
The debugger in WebRender uses the image crate to generate PNGs, and so
it only really needs the png codec feature from the image crate.
Differential Revision: https://phabricator.services.mozilla.com/D28351
--HG--
extra : moz-landing-system : lando
disclaimer: this isn't an *amazing* cleanup, but more of a major step that
unlocks the ability to do more minor cleanups and refinements. There's some
messy things and inconsistencies here and there, but we can hopefully iron
them out over time.
1. The primary change here is to move from
struct { common_fields, enum(specific_fields) }
to
enum (maybe_common_fields, specific_fields)
most notably this drops the common fields from a ton of things
that don't need them PopXXX, SetXXX, ClipChain, etc.
2. Additionally some types have had some redundant states shaved off,
for instance, rect no longer has *both* bounds and a clip_rect, as
the intersection of the two can be used. This was done a bit conservatively
as some adjustments will need to be done to the backend to fully eliminate
some states, and this can be done more incrementally.
2.5. As a minor side-effect of 2, we now early-reject some primitives whose
bounds and clip_rect are disjoint.
3. A HitTest display item has been added, which is just a Rect without
color. In addition to the minor space wins from this, this makes it much
easier to debug display lists
4. Adds a bunch of comments to the display list, making it easier to understand
things.
The end result of all these changes is a significantly smaller and easier to
understand display list. Especially on pages like gmail which have so many
clip chains. However this ultimately just makes text an even greater percentage
of pages (often 70-80%).
Differential Revision: https://phabricator.services.mozilla.com/D27439
--HG--
extra : moz-landing-system : lando
* make all enums repr(u8) (compiler bug blocking this long fixed)
* add display list stats feature
* remove cache markers (abandoned design)
* don't always push empty SetFilters before PushStackingContext
* remove dead pub methods
Differential Revision: https://phabricator.services.mozilla.com/D25845
--HG--
extra : moz-landing-system : lando
External scroll offsets are not propagated across reference frames.
When a perspective element scrolls relative to an ancestor scroll
frame, remove the effect of any external scroll offset during that
offset calculation.
Differential Revision: https://phabricator.services.mozilla.com/D28443
--HG--
extra : moz-landing-system : lando
disclaimer: this isn't an *amazing* cleanup, but more of a major step that
unlocks the ability to do more minor cleanups and refinements. There's some
messy things and inconsistencies here and there, but we can hopefully iron
them out over time.
1. The primary change here is to move from
struct { common_fields, enum(specific_fields) }
to
enum (maybe_common_fields, specific_fields)
most notably this drops the common fields from a ton of things
that don't need them PopXXX, SetXXX, ClipChain, etc.
2. Additionally some types have had some redundant states shaved off,
for instance, rect no longer has *both* bounds and a clip_rect, as
the intersection of the two can be used. This was done a bit conservatively
as some adjustments will need to be done to the backend to fully eliminate
some states, and this can be done more incrementally.
2.5. As a minor side-effect of 2, we now early-reject some primitives whose
bounds and clip_rect are disjoint.
3. A HitTest display item has been added, which is just a Rect without
color. In addition to the minor space wins from this, this makes it much
easier to debug display lists
4. Adds a bunch of comments to the display list, making it easier to understand
things.
The end result of all these changes is a significantly smaller and easier to
understand display list. Especially on pages like gmail which have so many
clip chains. However this ultimately just makes text an even greater percentage
of pages (often 70-80%).
Differential Revision: https://phabricator.services.mozilla.com/D27439
--HG--
extra : moz-landing-system : lando
* make all enums repr(u8) (compiler bug blocking this long fixed)
* add display list stats feature
* remove cache markers (abandoned design)
* don't always push empty SetFilters before PushStackingContext
* remove dead pub methods
Differential Revision: https://phabricator.services.mozilla.com/D25845
--HG--
extra : moz-landing-system : lando
Use the external scroll offsets provided by Gecko to:
(a) Offset primitives and clips by accumulated scroll offset.
(b) Adjust the scroll transforms and hit test results.
This allows primitives and clips to be stored in a true local space,
that is consistent between display lists, even if scrolling has
occurred. This is a step towards planned picture caching improvements.
Differential Revision: https://phabricator.services.mozilla.com/D27856
--HG--
extra : moz-landing-system : lando
We fail the assertion at the beginning of GpuCache::begin_frame
right now because we run the extract_updates call after building
frames for every document. This just moves the extract_updates
work to be per-document.
Differential Revision: https://phabricator.services.mozilla.com/D25251
--HG--
extra : moz-landing-system : lando
... and ensure that, if we do cleanup, we generate frames for every document.
Differential Revision: https://phabricator.services.mozilla.com/D25133
--HG--
extra : moz-landing-system : lando
