Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
It is helpful if window visibility state could be checked by debug overlay.
For now, it works only on Windows with compositor.
Differential Revision: https://phabricator.services.mozilla.com/D131807
Fenix makes use of the default clear color by setting it to a dark
color when the dark theme is enabled to avoid white flashes while
pages are loading. In bug 1663732 we hooked this functionality up to
webrender, however, it was only used by the draw compositor. Now with
software webrender on Android, we sometimes use
RenderCompositorLayersSWGL rather than the draw compositor, and users
are therefore experiencing white flashes during page loads.
This adds a clear_color argument to StartCompositing(), which
RenderCompositorLayersSWGL uses to set the CompositorOGL's clear
color. This patch also makes Renderer::clear_color not an Option
type, as we only ever used it in Some form, and that simplifies the
FFI.
Differential Revision: https://phabricator.services.mozilla.com/D119272
Fenix makes use of the default clear color by setting it to a dark
color when the dark theme is enabled to avoid white flashes while
pages are loading. In bug 1663732 we hooked this functionality up to
webrender, however, it was only used by the draw compositor. Now with
software webrender on Android, we sometimes use
RenderCompositorLayersSWGL rather than the draw compositor, and users
are therefore experiencing white flashes during page loads.
This adds a clear_color argument to StartCompositing(), which
RenderCompositorLayersSWGL uses to set the CompositorOGL's clear
color. This patch also makes Renderer::clear_color not an Option
type, as we only ever used it in Some form, and that simplifies the
FFI.
Differential Revision: https://phabricator.services.mozilla.com/D119272
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
In order to do that, move buffer type specific code into
`NativeSurfaceWayland` and create subclasses for SHM and EGL
buffers.
This should help identify bugs, improve the code structure for
additional buffer types (e.g. YUV) and makes us get closer
to the CA backend.
Also includes some minor unrelated cleanups.
Differential Revision: https://phabricator.services.mozilla.com/D115938
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
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
This requires us to plumb CompositorCapabilities to support the extra field.
This is complicated by the fact that since it is a Rust struct, it has no
default constructor that can pass through to C++ via bindings, so every
one of our RenderCompositors was forced to manually initialize fields. To
get around this brittle footgun, instead the structure is initialized on
the Rust side, and RenderCompositor's are encouraged to only change fields
that actually diverge from the defaults as passed in via pointer.
Finally, we can then do what we need to do, which is just to send the
ForceRedraw message that needs to happen based on what we know about
CompositorCapabilities.
Differential Revision: https://phabricator.services.mozilla.com/D106246
This requires us to plumb CompositorCapabilities to support the extra field.
This is complicated by the fact that since it is a Rust struct, it has no
default constructor that can pass through to C++ via bindings, so every
one of our RenderCompositors was forced to manually initialize fields. To
get around this brittle footgun, instead the structure is initialized on
the Rust side, and RenderCompositor's are encouraged to only change fields
that actually diverge from the defaults as passed in via pointer.
Finally, we can then do what we need to do, which is just to send the
ForceRedraw message that needs to happen based on what we know about
CompositorCapabilities.
Differential Revision: https://phabricator.services.mozilla.com/D106246
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
We need to be able to delay instantiation of the drawing region until after we have the
dirty rects from start_compositing. This was currently not routed to RenderCompositor,
which is required to do this. Further, SwCompositor needs to always keep track of the
RenderCompositor that it is associated with regardless of whether or not it is a native
compositor so that this hook can be properly engaged.
Differential Revision: https://phabricator.services.mozilla.com/D100974
Aside from on Windows, we do not appear to handle device resets properly
without the GPU process. This patch adds in the necessary plumbing to
handle the device reset properly. It also ensures that whenever we check
for a device reset reason, we handle all of the reasons (e.g. not just
the NV video memory purge reset reason) to ensure they are not lost, and
handles them all consistently in the same manner.
It also tracks the number of device resets for thresholding purposes
with an in process compositor. While it will only disable WebRender on
Linux at this time, it will put a note in the critical log if the
threshold was exceeded on all platforms. This may prove useful in
evaluating whether or not we should do the same everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D98705
