The renderer thread is at the end of the rendering pipeline. For smoothness it is important that it completes its work quickly as soon as it receives some. It does not produce work for other threads so we don't risk of causing some build up. On the other hand, the higher priority will help with with avoiding some cases of congestion of work coming from the content process.
This only bumps the priority of the renderer thread as opposed to the entire GPU process (Blink does the latter). This is because we currently have too many thread on the GPU process so there is a risk of completely starving other processes. It's still something we want to consider and might be safer after we have done the work of reducing the number of threads.
Differential Revision: https://phabricator.services.mozilla.com/D143056
SimulateDeviceReset() works differently from actual device reset handling. It seems better to make SimulateDeviceReset() more similar to actual device reset handling.
Differential Revision: https://phabricator.services.mozilla.com/D140161
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
RenderCompositorANGLE::ShutdownEGLLibraryIfNecessary() is not necessary since Bug 1656034 fix. Device reset handling could be more platform independent.
Differential Revision: https://phabricator.services.mozilla.com/D130960
RenderCompositorANGLE::ShutdownEGLLibraryIfNecessary() is not necessary since Bug 1656034 fix. Device reset handling could be more platform independent.
Differential Revision: https://phabricator.services.mozilla.com/D130960
This patch adds the necessary IPDL plumbing to allow us to create WebGL
instances off the main thread in the content process, and to execute
them on the Renderer thread in the compositor process.
Differential Revision: https://phabricator.services.mozilla.com/D127839
This patch adds plumbing to keep track of why we request frames to be rendered.
This information is then displayed in gecko profile markers on the renderer thread as well as in profiler HUD counters (See "Render reasons" in profiler.rs).
Differential Revision: https://phabricator.services.mozilla.com/D127274
It leads to OpenGL errors, as we must initialize a webrender Device in
order to initialize the shaders, and this Device attempts to use
OpenGL commands not supported by the GL context. For example the GL
context may only support GLES 2, hence why we are using SWGL in the
first place.
Differential Revision: https://phabricator.services.mozilla.com/D120356
The background hang monitor uses the same timing thresholds as the one used by
the compositor thread, for similar reasons.
Differential Revision: https://phabricator.services.mozilla.com/D120117
Instead of warning against callers directly accessing the thread message loop,
actuually prevent them from doing so. This is also a preliminary step to
changing the type of the internally-created thread, which will no longer
directly expose its message loop.
Differential Revision: https://phabricator.services.mozilla.com/D119562
Right now X11-only builds will use `RendenderCompositorOGL` with EGL,
which could lead to unexpected bugs that are hard to diagnose.
It also makes code harder to read if code in `MOZ_WAYLAND` blocks
is used by the X11 backend.
While on it, rename and reorder `PauseRemoteRenderer()` so it matches
its counterpart `MaybeResumeCompositor()` better.
Note: This revision was accepted in D116315 but some bug in lando
required a recreation.
Differential Revision: https://phabricator.services.mozilla.com/D116530
This implements a mostly working native backend for Wayland. It can
be enabled via `gfx.webrender.compositor.force-enabled`.
The focus here was to get a basic structure in place while mini-
mising changes in shared code.
Known issues and limitations:
- No readback - this will likely require an internal compositor
again, as Wayland doesn't allow easily allow readback of the
composited image, at least not without asking for permission.
Alternatively, a new Wayland extension could be written for it.
- Frame-call related issues when using a compositor that optimizes
them (e.g. Gnome-Shell). This will be fixed in a follow-up, in
the mean time disabling `widget.wayland.opaque-region.enabled`
and `widget.wayland.vsync.enabled` works around the issues.
- Only works on Weston or very recent versions of Gnome-Shell, see
bug 1699754
Differential Revision: https://phabricator.services.mozilla.com/D111662
We want to use nsExpirationTracker to decide when we should unmap shared
surfaces from our address space. This relies upon the observer service
and we need to be both initialized and shutdown on the main thread to
add/remove the observer. SharedSurfacesParent is already initialized on
the main thread, and we just need to complete shutdown on the main
thread.
Differential Revision: https://phabricator.services.mozilla.com/D109439
GLContext for CompositorOGL does not need depth buffer. Then it is better to re-create the mSingletonGL during fallback to RenderCompositorOGLSWGL.
Differential Revision: https://phabricator.services.mozilla.com/D110057
We want to use nsExpirationTracker to decide when we should unmap shared
surfaces from our address space. This relies upon the observer service
and we need to be both initialized and shutdown on the main thread to
add/remove the observer. SharedSurfacesParent is already initialized on
the main thread, and we just need to complete shutdown on the main
thread.
Differential Revision: https://phabricator.services.mozilla.com/D109439
We want to use nsExpirationTracker to decide when we should unmap shared
surfaces from our address space. This relies upon the observer service
and we need to be both initialized and shutdown on the main thread to
add/remove the observer. SharedSurfacesParent is already initialized on
the main thread, and we just need to complete shutdown on the main
thread.
Differential Revision: https://phabricator.services.mozilla.com/D109439
Confirmed that the change work on Mali-400 MP device.
GLContextProviderEGL::CreateForCompositorWidget() with aWebRender=true failed to create GLContext when GLES3 is not supported on device. When aWebRender=false, it does not request depth buffer nor GLES3. Though when android device supports GLES3, GLES3 context was created on android devices that I tested.
Differential Revision: https://phabricator.services.mozilla.com/D109015
Name of Singleton is commonly used in gecko.
Name of SharedGL is confusing. It looks like "shared context", but it is not. The GL context is actually a singleton GLContext that is used by all WebRender. Each window creates one EGLSurface for each window. EGLSurface is switched for each window rendering.
Differential Revision: https://phabricator.services.mozilla.com/D108714
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Mike Hommey
Nicolas Silva
Andrew Osmond
Florian Quèze
sotaro
Iulian Moraru
Narcis Beleuzu
Alexandru Michis
criss
Jamie Nicol
Brad Werth
Csoregi Natalia
Robert Mader
Noemi Erli
Butkovits Atila
stransky
Jan Alexander Steffens (heftig)