In this patch, we ask the media engine to return a handle for shareable
dcomp surface, which will then be packaged into a new texture data type
and being shared with the GPU process via the video bridge.
DcompSurfaceImage is the image which contains the handle texture data,
which doesn't support being accessed in the content process. When the
compositor uploads the image to the GPU process, the corresponding
texture host will be created.
The render texture host will be created by that texture host, and it
will be used in DCLayerTree. In DCLayerTree, we create a new type of
surface for our dcomp handle. DCSurfaceHandle will ask the render
texture host to reconstruct the surface by the handle shared from the
remote process (the handle is actually duplicated to the parent process
first due to the sandbox policy, and then be duplicated to the GPU
process later)
DCSurfaceHandle will attach that surface to its visual in order to
display the video frame directly. In the whole process, it's not
possible for Gecko to access any decoded video data which is protected by the
media engine itself.
Depends on D149941
Differential Revision: https://phabricator.services.mozilla.com/D151019
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
We need to pad e.g. nv12 4:2:0 formats in order to have integer-sized
chroma planes.
But also to avoid needing laser-focused testing for this case, just
unconditionally pad odd-sizes to even numbers.
* Test handling of odd-number-sized surfaces.
Differential Revision: https://phabricator.services.mozilla.com/D152797
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
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
If MaybeRecordFrame is called after EndFrame, this means we are reading from
the back buffer state immediately after a call to SwapBuffers. The state of
the back buffer is undefined in that scenario, and mostly was just returning
old frames. We actually want to call MaybeRecordFrame before EndFrame, so we
get the valid contents of the back buffer before it is swapped out.
Differential Revision: https://phabricator.services.mozilla.com/D151988
Current implementation quits video overlay rendering on the error. If the error continues, the video overlay is not rendered correctly. Then it seems better to disable video overlay on the error.
Differential Revision: https://phabricator.services.mozilla.com/D151350
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
Removes the last usage of the old-style clip-id parenting in
gecko. These paths passed the clip parent, but shouldn't be
necessary (all tests pass without them). Landing as a small
patch that's easy to bisect and back out if it does cause any
regression.
Differential Revision: https://phabricator.services.mozilla.com/D150050
The previous patch in this bug added crash annotations for the number
of total and currently active renderers. However, we are actually
interested in these values when the EGL surface creation fails, as
opposed to when we crash later on after failing to recover. This patch
adds the values to gfxCriticalNote at the time of the error.
Differential Revision: https://phabricator.services.mozilla.com/D150365
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
