Currently splane splitters are stored in the built scene and reallocated with every new scene.
This patch moves the responsibility of storing/recycling the plane splitters to the frame builder so that they can be reused in more cases. The scene builder only needs to track splitter indices, it doesn't use the splitter objects themselves.
Alone this patch does not make a large difference because the current version of the plane_split crate reallocates everything each frame. The next version of plane_split does a much better job of recycling allocations, and applying this patch on top of it makes a large difference.
Differential Revision: https://phabricator.services.mozilla.com/D160363
New plane_split version with much faster BSP tree.
The main source of churn is plane_split not being generic over the unit tag anymore.
Differential Revision: https://phabricator.services.mozilla.com/D160362
For SWGL on ARM, we implement sqrt(N) as N * inversesqrt(N). This means we don't
properly handle zero unless we explicitly check for it. Otherwise, a NaN ends up
getting produced erroneously.
Differential Revision: https://phabricator.services.mozilla.com/D161107
Port gradient stops to be stored in the gpu-buffer rather than
the gpu-cache. The intent is to land a small use case for the
gpu-buffer code, which will allow us to get an idea if there's any
unexpected performance or driver bugs from the new gpu-buffer code,
before making wider use of this to replace the gpu-cache.
Differential Revision: https://phabricator.services.mozilla.com/D160743
This test ensures that a y-flip works correctly along with a 90/270
degree transform and a non-square content size.
Depends on D160817
Differential Revision: https://phabricator.services.mozilla.com/D160818
Gecko uses the webrender API DisplayListBuilder.push_computed_frame()
to create a reference frame with a transform specified by a scale_from
size, an optional vertical_flip, and a rotation. This is used for
video.
This patch adds the ability to test this API from wrench yaml. An
example of a test using this capability can be found in the next patch
in this series.
Depends on D160816
Differential Revision: https://phabricator.services.mozilla.com/D160817
On Android, videos with a hard-coded rotation were being incorrectly
cropped when rendering. This is due to a buggy transform calculation
in SceneBuilder.build_reference_frame().
To apply the y-flip, we scale the height by -1, then translate the y
offset by content_size.height. However, as this video contains an 90
degree rotation, this means we actually end up translating by the
video's width rather than its height. Because the width and height are
different sizes in this video, this means the video is rendered at an
incorrect offset and is cropped. To fix this, ensure we translate by
content_size.width instead for 90 or 270 degree rotations.
Note that this only occured on Android because SurfaceTextureClient is
the only texture client type that sets the ORIGIN_BOTTOM_LEFT texture
flag, thereby causing a y-flip in this location.
Differential Revision: https://phabricator.services.mozilla.com/D160816
Clip tile shaders don't output the vertex W, so that SWGL can't detect if we're trying
to render something with perspective or not. swgl_drawSpan functions then get invoked
as if no perspective was used. In this case, we need to explicitly check to see if
there is perspective, or rather, that the W value varies along the span.
Differential Revision: https://phabricator.services.mozilla.com/D160464
In bug 1787520 we discovered a driver bug affecting Mali-G78 devices,
and added a workaround for it - avoiding invalidating no-longer-needed
render targets at the end of each render pass. It now transpires this
bug also affects Mali-G710 GPUs, so this patch applies the same
workaround for those devices too.
Differential Revision: https://phabricator.services.mozilla.com/D159515
When building the GPUBuffer during the prepare pass, we want to be
able to refer to the UV rect (and other information) about images
and render tasks. However, we don't know this information until
after the resource cache block that occurs after prepare (waiting
for blob / glyph worker threads to complete).
Previously, we would defer these queries until batching and then
reference these via a GPU cache address in the instances, which
is complicated and inefficient (making instances larger than they
need to be).
With this change, GPUBuffer supports recording "patch" locations in
the buffer that UV rects should be added. After the render task
graph is built, the GPUBuffer can resolve and patch those locations,
meaning that batching is much simpler (and reducing the number of
indirect fetches required in vertex shaders).
Differential Revision: https://phabricator.services.mozilla.com/D159236
If an external image shows up multiple times while using a different image rendering
setting on each instance, we can erroneously call handler.lock() for each instance in
parallel, thus defaulting to the last image rendering setting supplied for all instances
in that batch.
To work around this, we get rid of the concept of having RenderTextureHosts maintain and
set the image rendering state, which results in a nice simplification. Then, when we go
to actually bind an external image inside WebRender, we set the image rendering state
at that point, so that regardless of how many instances of an external image are locked
simultaneously, we always use the correct image rendering setting for a batch.
Differential Revision: https://phabricator.services.mozilla.com/D158920
For some time, we've been wanting to move away from use of the GPU
cache, due to driver complexity and performance bugs when updating
the shared texture.
Instead, we can create one or more buffers that contain the relevant
information for the primitives that are currently dirty + visible,
and being batched for drawing.
By pooling these and only reusing them when the GPU has finished
referencing them, we hope to simplify the management of GPU buffers
compared to the GPU cache, and also remove driver stalls we see
in various cases related to the GPU cache (note: the buffer recycling
will be implemented in follow up commits).
For now, this basic infrastructure will allow us to do some experiments
and profiling with using this, while building some of the planned
performance optimizations for clip-mask rendering.
Differential Revision: https://phabricator.services.mozilla.com/D157284
On the Pixel 6 family devices we are seeing frequent image corruption
issues on some websites, which started following the Android 13
upgrade. This can be avoided by not invalidating the no-longer-needed
render targets at the end of each render pass. This is only an
optimization anyway, so is safe to skip.
The Android 13 update upgraded the Mali driver from version v1.r32p1
to v1.r36p0. As we did not encounter this bug prior to the Android 13
update, this patch only applies the workaround on driver versions
v1.r36p0 and above. It's possible other GPUs than the G78 are also
affected, but for now we limit the workaround to just this GPU. We can
re-evaluate if and when we receive bug reports from users on other
GPUs.
Differential Revision: https://phabricator.services.mozilla.com/D157116
On the Pixel 6 family devices we are seeing frequent image corruption
issues on some websites, which started following the Android 13
upgrade. This can be avoided by not invalidating the no-longer-needed
render targets at the end of each render pass. This is only an
optimization anyway, so is safe to skip.
The Android 13 update upgraded the Mali driver from version v1.r32p1
to v1.r36p0. As we did not encounter this bug prior to the Android 13
update, this patch only applies the workaround on driver versions
v1.r36p0 and above. It's possible other GPUs than the G78 are also
affected, but for now we limit the workaround to just this GPU. We can
re-evaluate if and when we receive bug reports from users on other
GPUs.
Differential Revision: https://phabricator.services.mozilla.com/D157116
There is a slow rendering path for subpixel AA on hardware that
doesn't support dual-source blending. However, we never actually
enable that path (as `force_subpixel_aa` is never modified by
Gecko) now as almost all hardware supports it. If ever running
Firefox on a machine without dual-source blending, grayscale
text AA will be enabled by default, or SW-WR can be used if
subpixel AA is desired.
Differential Revision: https://phabricator.services.mozilla.com/D156234
Instead of setting a ceiling on how much we are willing to allocate, we
should always try to reallocate a buffer the same size that we used
before. If we cannot, we should fail gracefully and just not preallocate
at all. This should help with profiles where we consistently need a
larger payload buffer than the previous maximum, while minimizing OOM
crashes on the other side, where our preallocations fail and/or are more
than the next display list update actually requires.
Differential Revision: https://phabricator.services.mozilla.com/D154951
And lazily create it when first surface is created. This prevents us
unnecessarily holding on to that memory when a compositor has no
surfaces, ie when the tab is backgrounded on Android. While each depth
texture may only be a few megabytes, this quickly adds up on Android
where each tab has its own compositor.
Differential Revision: https://phabricator.services.mozilla.com/D154636
When the webrender render backend receives a memory pressure event,
call a new function TileCacheInstance.memory_pressure() for each tile
cache owned by the render backend. This destroys each compositor tile
and surface owned by the cache. By additionally setting the
NativeTileId for each tile to None, we will automatically allocate new
tiles if required during the next frame build.
On Android with SWGL enabled, this helps prevent ballooning memory
usage when opening several tabs, as memory pressure events are
triggered when a tab is backgrounded.
Differential Revision: https://phabricator.services.mozilla.com/D154635
And lazily create it when first surface is created. This prevents us
unnecessarily holding on to that memory when a compositor has no
surfaces, ie when the tab is backgrounded on Android. While each depth
texture may only be a few megabytes, this quickly adds up on Android
where each tab has its own compositor.
Depends on D154635
Differential Revision: https://phabricator.services.mozilla.com/D154636
When the webrender render backend receives a memory pressure event,
call a new function TileCacheInstance.memory_pressure() for each tile
cache owned by the render backend. This destroys each compositor tile
and surface owned by the cache. By additionally setting the
NativeTileId for each tile to None, we will automatically allocate new
tiles if required during the next frame build.
On Android with SWGL enabled, this helps prevent ballooning memory
usage when opening several tabs, as memory pressure events are
triggered when a tab is backgrounded.
Differential Revision: https://phabricator.services.mozilla.com/D154635
There is a lot going on in renderer.rs, the initialization code takes a non-negligible chunk of it and touches all aspects of WebRender including setting up all of the threads. This patch moves it into its own init module.
In addition, RendererOptions is renamed into WebRenderOptions to better reflect that it configures every aspect of the engine, and init::create_webrender_instance replaces Renderer::new.
This a rebased version of an pld patch approved by kvark a while back.
Differential Revision: https://phabricator.services.mozilla.com/D103767
There is a lot going on in renderer.rs, the initialization code takes a non-negligible chunk of it and touches all aspects of WebRender including setting up all of the threads. This patch moves it into its own init module.
In addition, RendererOptions is renamed into WebRenderOptions to better reflect that it configures every aspect of the engine, and init::create_webrender_instance replaces Renderer::new.
This a rebased version of an pld patch approved by kvark a while back.
Differential Revision: https://phabricator.services.mozilla.com/D103767
This patch uses a single FT_Library for all font threads (even across separate windows)
within WebRender. It maintains a mapping from FontTemplate to a cached FT_Face that will
be traded to any font thread that requests it on a first-come-first-serve basis. This
FT_Face is guarded by a mutex to ensure that no other worker thread can use it while it
is in-use by the first requesting thread.
In general it is safe to use different FT_Faces on different threads so long as they are
distinct. However, the snag in this is that FT_LcdFilter state is stored globally in the
FT_Library, even while it is supplied per-FontInstance. To workaround this, we need to
keep track of how many threads are currently rasterizing glyphs with the FT_LcdFilter
state and wait for them to all finish before we can change the FT_LcdFilter to what
the next group of incoming jobs expects. FontContext::begin_rasterize/end_rasterize hooks
were added to support this. While there seems to be some support in newer FreeType
versions for per-FT_Face LcdFilter settings, it doesn't allow disabling the LcdFilter
or using legacy settings, so we are still suck using the global setting instead.
To further reduce memory usage, this patch also no longer allocates a separate FT_Face
for FontVariations. Instead, since the FT_Face must be locked to a single thread anyway,
it now just uses FT_Set_Var_Design_Coordinates on the single FT_Face for the font before
loading the batch of glyphs associated with the FontVariations. So regardless of how many
different variations are used for a font, it will only allocate a single FT_Face.
Normally, rayon's par_iter is used to scatter glyphs from a single font request onto
multiple threads which works against the one-font-per-thread model needed here. This
adds a FontContext::distribute_across_threads hook to control whether or not par_iter
should be used so that we can disable that behavior for this case, where instead we just
want to process each glyph serially within the scope of a single worker for a given
font request.
Differential Revision: https://phabricator.services.mozilla.com/D153715
This patch uses a single FT_Library for all font threads (even across separate windows)
within WebRender. It maintains a mapping from FontTemplate to a cached FT_Face that will
be traded to any font thread that requests it on a first-come-first-serve basis. This
FT_Face is guarded by a mutex to ensure that no other worker thread can use it while it
is in-use by the first requesting thread.
In general it is safe to use different FT_Faces on different threads so long as they are
distinct. However, the snag in this is that FT_LcdFilter state is stored globally in the
FT_Library, even while it is supplied per-FontInstance. To workaround this, we need to
keep track of how many threads are currently rasterizing glyphs with the FT_LcdFilter
state and wait for them to all finish before we can change the FT_LcdFilter to what
the next group of incoming jobs expects. FontContext::begin_rasterize/end_rasterize hooks
were added to support this. While there seems to be some support in newer FreeType
versions for per-FT_Face LcdFilter settings, it doesn't allow disabling the LcdFilter
or using legacy settings, so we are still suck using the global setting instead.
To further reduce memory usage, this patch also no longer allocates a separate FT_Face
for FontVariations. Instead, since the FT_Face must be locked to a single thread anyway,
it now just uses FT_Set_Var_Design_Coordinates on the single FT_Face for the font before
loading the batch of glyphs associated with the FontVariations. So regardless of how many
different variations are used for a font, it will only allocate a single FT_Face.
Normally, rayon's par_iter is used to scatter glyphs from a single font request onto
multiple threads which works against the one-font-per-thread model needed here. This
adds a FontContext::distribute_across_threads hook to control whether or not par_iter
should be used so that we can disable that behavior for this case, where instead we just
want to process each glyph serially within the scope of a single worker for a given
font request.
Differential Revision: https://phabricator.services.mozilla.com/D153715
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
Including glean_parser 6.1.1
Two important things in there:
* glean_parser: [data-review] Include extra keys' names and descriptions in data review template
* Glean: Derive `serde::{Deserialize, Serialize}` on `Lifetime` and `CommonMetricData`
Differential Revision: https://phabricator.services.mozilla.com/D149381
As part of the frame building work being done, the PrimitiveInstance
struct will change significantly (most of the state will be moved
to the primitive template, instance will be closer to an index +
some visibility state).
`prepared_frame_id` is no longer relevant (it can't be incorrect
now due to the way prims are reset). The chase is is not used or
maintained, and would need to be quite different after the changes
mentioned above anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149025
Since backdrop_surface is not cleared on prepare_for_new_scene, it's possible
that the tile cache might be carrying "old" backdrop info. Existing code
correctly handles this case *as long as* the new scene also has a backdrop.
This change is necessary to make sure that old backdrop info is cleared
even when the new scene does not contain a backdrop.
Differential Revision: https://phabricator.services.mozilla.com/D148848
It's not necessary to clear the tile cache backdrop surface when a new
scene arrives. Doing so has unintended consequences because clearing the
backdrop surface forces the destruction of the associated native surface.
That native surface will very likely just have to be recreated. If the new
scene doesn't have a backdrop, or has a different backdrop, the logic in
take_context is sufficient to destroy the old one.
Depends on D148704
Differential Revision: https://phabricator.services.mozilla.com/D148705
This ensures that the native surfaces for color backdrops are destroyed
when the tile cache itself is destroyed.
Depends on D148678
Differential Revision: https://phabricator.services.mozilla.com/D148704
It's not necessary to clear the tile cache backdrop surface when a new
scene arrives. Doing so has unintended consequences because clearing the
backdrop surface forces the destruction of the associated native surface.
That native surface will very likely just have to be recreated. If the new
scene doesn't have a backdrop, or has a different backdrop, the logic in
take_context is sufficient to destroy the old one.
Depends on D148704
Differential Revision: https://phabricator.services.mozilla.com/D148705
This ensures that the native surfaces for color backdrops are destroyed
when the tile cache itself is destroyed.
Depends on D148678
Differential Revision: https://phabricator.services.mozilla.com/D148704
This patch is rolling back changeset 06c57c0af21d which is Phabricator
revision D147566, plus adding some comments indicating the desire to
restore some of the intent of that code. The effect of this rollback is to
activate native color layers only if they cover the entire scrollable
area, not just the visible area. This is necessary to ensure correct
visuals as tiles are scrolled into view, when those tiles show something
other than the backdrop color.
Differential Revision: https://phabricator.services.mozilla.com/D148541
The duplications arise from a Glean update, which has some of those as
transitive dependencies.
Upgrading Clap and others here reduces the duplication.
Differential Revision: https://phabricator.services.mozilla.com/D147659
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062
Division by zero (and also close to zero values) can cause the interpolant step to
become infinite which can feed bogus values into the shader. Since the left and
right edges in this case are essentially at the same position, we can freely just
choose interpolants from either the left or right edge. Just set the step scale
to zero in this case so we default to the interpolant values from the left edge
and don't step them at all in this case.
Differential Revision: https://phabricator.services.mozilla.com/D148232
This calculates the visible area of the TileCache, and compares against that area
for four purposes:
1) Backdrops must cover only the visible area, not the tile coverage area.
2) Primitives only obstruct the backdrop if they appear in the visible area.
3) Backdrop candidates opaque rects are clipped to the visible area.
4) Subpixel AA is allowed as long as the backdrop rect covers the visible
tiling area, not necessarily the entire tiling area.
All these changes ensure that if a tile coverage area is larger than the window,
backdrops are only considered and created for the visible area.
Note that this has no effect on the contents of tiles that intersect the
backdrop area, wholly or partly. Those tiles, per earlier parts of this
patch, are only set with is_visible=false, which means that they are not
sent to the compositor this frame. The tile surfaces still exist, etc.
This is all in alignment with the idea that we want the entire slice area
(covered by the tiles) to be ready to be scrolled in.
Differential Revision: https://phabricator.services.mozilla.com/D147566
In addition to creating the backdrop surface when it is detected, this also
turns off the rendering of tiles in that same slice. Virtual tiles
associated with compositor surfaces (external or not) will still be
rendered.
This adds a clip check to avoid pushing tiles that are fully clipped out. It
also adds a similar check for compositor surfaces.
Depends on D127175
Differential Revision: https://phabricator.services.mozilla.com/D128131
This only allows native compositors to claim this capability, without changing
any compositors to do so. In Part 4, the macOS native compositor claims this
capability in conjunction with adding the code that handles the color layers.
Differential Revision: https://phabricator.services.mozilla.com/D127175
This can happen when there is a long nested chain of backdrop-filters
and float inaccuracies cause the final capture primitive to be culled.
Differential Revision: https://phabricator.services.mozilla.com/D147704
This calculates the visible area of the TileCache, and compares against that area
for three purposes:
1) Backdrops must cover only the visible area, not the tile coverage area.
2) Primitives only obstruct the backdrop if they appear in the visible area.
3) Backdrop candidates opaque rects are clipped to the visible area.
All these changes ensure that if a tile coverage area is larger than the window,
backdrops are only considered and created for the visible area.
Note that this has no effect on the contents of tiles that intersect the
backdrop area, wholly or partly. Those tiles, per earlier parts of this
patch, are only set with is_visible=false, which means that they are not
sent to the compositor this frame. The tile surfaces still exist, etc.
This is all in alignment with the idea that we want the entire slice area
(covered by the tiles) to be ready to be scrolled in.
Differential Revision: https://phabricator.services.mozilla.com/D147566
In addition to creating the backdrop surface when it is detected, this also
turns off the rendering of tiles in that same slice. Virtual tiles
associated with compositor surfaces (external or not) will still be
rendered.
This adds a clip check to avoid pushing tiles that are fully clipped out. It
also adds a similar check for compositor surfaces.
Depends on D127175
Differential Revision: https://phabricator.services.mozilla.com/D128131
This only allows native compositors to claim this capability, without changing
any compositors to do so. In Part 4, the macOS native compositor claims this
capability in conjunction with adding the code that handles the color layers.
Differential Revision: https://phabricator.services.mozilla.com/D127175
Cristian Tuns
Jim Blandy
Nicolas Silva
Jan-Erik Rediger
Lee Salzman
ohall-m
Glenn Watson
Jamie Nicol
Chris H-C
Bas Schouten
Ashly Hale
pmcmanis
Butkovits Atila
Jeff Muizelaar
Mike Hommey
Andrew Osmond
Csoregi Natalia
Noemi Erli
Iulian Moraru
criss
Brad Werth
Travis Long
Norisz Fay
Bogdan Szekely
smolnar
Dan Robertson
Bobby Holley
Marian-Vasile Laza
Narcis Beleuzu