RenderTextureHostWrapper::AsRenderTextureHostSWGL() is not implemented. It is necessary for wr_swgl_lock_composite_surface().
Differential Revision: https://phabricator.services.mozilla.com/D163556
it started as a single method new_frame_ready with a composite parameter, to be split into two functions that end up calling the same HandleFrameOneDoc with a composite parameter so the extra function doesn't provide anything.
Differential Revision: https://phabricator.services.mozilla.com/D162299
Only transactions that contain the generate_frame flag are tracked by the pending frame and frame build counters.
This patch attempts to make this clearer with two small adjustments:
Firstly by putting the IncPendingFrameCount call right next to Transaction::GenerateFrame.
Secondly, undoing the hack in wr_notifier_wake_up. The latter is called outside of normal rendered/tracked frames and was calling HandleFrameOneDoc which decrements the rendered frame counter. To compensate it had to manually increment both counters via IncPendingFrameCount and manually decrement the built frame counter via DecPendingFrameBuildCount. Instead this patch introduces the aTrackedFrame argument so that HandleFrameOneDoc only fiddles with the counters when needed and wake_up does not have to hack around it.
Differential Revision: https://phabricator.services.mozilla.com/D162298
The previous name could have related to any situation where a composite is needed such as when animating or receiving transactions, but the function is actually specifically about scheduling a new composite if the previous one was skipped.
Differential Revision: https://phabricator.services.mozilla.com/D162295
- Ensure that the pending frame count is decremented by HandleFrameOneDoc even after some of the rare early-outs.
- Always check TooManyPendingFrames in CompositeToTarget.
It is unclear that these will actually catch (all of) the extraneous skipped frames. If anything, the simplification will make further investigation easier.
Differential Revision: https://phabricator.services.mozilla.com/D162294
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
Wait at RenderCompositorANGLE::WaitForGPU() blocks render thread. It is not good.
Since Bug 1589718 fix, AsyncImagePipelineManager::NotifyPipelinesUpdated() works without wait at RenderCompositorANGLE::WaitForGPU(). Directly bounded texture buffers are released by using aLastCompletedFrameId.
Differential Revision: https://phabricator.services.mozilla.com/D158478
In Bug 1645677 we disable rendering and free compositor resources on GTK unmap signal when GtkWindow is hidden.
That ensures we create EGLSurface again when GtkWindow is shown and we use recent wl_surface on Wayland.
We use Resume() compositor signal to force compositor to re-create EGLSurface over new wl_surface.
RenderCompositorSWGL uses different mechanism but underlying WindowSurfaceWaylandMB is also deleted on unmap
and we need to request full repaint on Resume() as new WindowSurfaceWaylandMB was created.
Differential Revision: https://phabricator.services.mozilla.com/D158322
There is a case that SwapChain surface handle is not closed. It should be closed correctly. It caused the problem on NVIDIA gpu.
Differential Revision: https://phabricator.services.mozilla.com/D158236
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
On Android, SurfaceTextures provide a transform matrix that should be
applied to texture coordinates when sampling from the texture. Prior
to bug 1731980 we ignored this value, and simply y-flipped the video
instead. On most devices the transform is just a y-flip, so this
produced the correct results. However, on some devices the transform
included a scale as well as the y-flip, meaning that we rendered
videos at an incorrect size.
The fix for bug 1731980 was to correctly apply the transformation.
However, it now appears that on Mediatek 6735 devices the transform
provided by the system is incorrect. On these devices, videos were
rendered correctly when we ignored the transform and just did a
y-flip, and now that we apply the transform videos are rendered at the
wrong size.
This patch makes it so that we override the system-provided transform
on these devices with a simple y-flip. The existing mIgnoreTransform
flag has been changed to an optional "transform override" value to
achieve this. We ensure that we only override the transform for
SurfaceTextures that are output from a MediaCodec, to ensure that we
don't accidentally apply the wrong transform to SurfaceTextures
attached to other sources.
Differential Revision: https://phabricator.services.mozilla.com/D155706
At point of display, we need the TextureHost to know whether or not its
texture was created from a DRM Image. The throughline of data is:
Image -> TextureClient -> TextureHost
The TextureClient is generated by the Image, so it has access to the DRM
state of the Image, but the TextureHost is built from the raw texture data
and from TextureFlags. This patch updates TextureFlags to include a
DRM_SOURCE bit for use by the TextureHost.
The TextureClient and TextureHost are platform-specific classes. The
creation of the TextureClient by the Image is done in a platform-specific
subclass of Image. This patch only implements this pipeline for macOS.
There doesn't seem to be a way to do this in cross-platform classes, but
other platforms can follow the pattern used here.
Depends on D155295
Differential Revision: https://phabricator.services.mozilla.com/D155296
While looking at the some of the Rust threads in the profiler they were always
appearing gray, which are not easy to follow/understand. Adding
Graphics::Rasterization category to these code paths allows us to show the
appropriate category for WRWorker threads. It changes the category color to
green as well which is easier to follow and understand.
See the following profiler links:
Before: https://share.firefox.dev/3egkhRC
After: https://share.firefox.dev/3cGEcca
Timeline color is different as well as the colors in the Call Tree.
Differential Revision: https://phabricator.services.mozilla.com/D156204
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
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
sotaro
Nicolas Silva
Jens Stutte
David Shin
Lee Salzman
stransky
Butkovits Atila
Kelsey Gilbert
Jamie Nicol
Brad Werth
Mike Hommey
Marian-Vasile Laza
Cristian Tuns
Nazım Can Altınova
Glenn Watson
Andi-Bogdan Postelnicu
alwu
Noemi Erli
Timothy Nikkel
Iulian Moraru
Emilio Cobos Álvarez
Bas Schouten
Narcis Beleuzu