layers.
This makes the macOS native compositor claim the ability to handle color
layers and makes NativeLayerCA actually do it. Color layers have a different
structure than other layers. Color layers apply the color to the
wrappingCALayer, and have no contentCALayer at all. That means that the
color layers are always sized to the layer's clip rect.
This also contains a drive-by fix to handle the case where an mOpaquenessTintLayer
exists when mMutatedSpecializeVideo is set to true. Before this change, in such a
case, the opaqueness layer will not be associated with the recreated wrapping layer.
Depends on D128131
Differential Revision: https://phabricator.services.mozilla.com/D128545
layers.
This makes the macOS native compositor claim the ability to handle color
layers and makes NativeLayerCA actually do it. Color layers have a different
structure than other layers. Color layers apply the color to the
wrappingCALayer, and have no contentCALayer at all. That means that the
color layers are always sized to the layer's clip rect.
This also contains a drive-by fix to handle the case where an mOpaquenessTintLayer
exists when mMutatedSpecializeVideo is set to true. Before this change, in such a
case, the opaqueness layer will not be associated with the recreated wrapping layer.
Depends on D128131
Differential Revision: https://phabricator.services.mozilla.com/D128545
This makes the macOS native compositor claim the ability to handle color
layers and makes NativeLayerCA actually do it. Color layers have a different
structure than other layers. Color layers apply the color to the
wrappingCALayer, and have no contentCALayer at all. That means that the
color layers are always sized to the layer's clip rect.
This also contains a drive-by fix to handle the case where an mOpaquenessTintLayer
exists when mMutatedSpecializeVideo is set to true. Before this change, in such a
case, the opaqueness layer will not be associated with the recreated wrapping layer.
Differential Revision: https://phabricator.services.mozilla.com/D128545
This was originally implemented in D111662 to work around a crash
that otherwise would get triggered in Gnome/Mutter.
The fix for that crash has been available for a couple of month now,
thus remove the workaround again.
This may help preventing flickering for menus in certain situations.
Differential Revision: https://phabricator.services.mozilla.com/D137251
Note: Sorry in advance that this patch is so big. Unfortunately
splitting it up would create lots of redundant changes.
This should be the last big refactoring for the Wayland compositor
backend for now.
Up until now SurfacePoolWayland was a pool of actual `wl_surface`s,
as before bug 1718569 we had no direct access to `wl_buffer`s when
using EGL. However, the way `SurfacePoolCA` manages native surfaces
is closer to what in Wayland terminology would be a buffer pool:
buffers are heavy-weight and expansive to allocate, while
`wl_surface` objects are cheap to recreate.
So instead of having a pool of surfaces, each of them having its
own pool of buffers, make `wl_surface`s part of tiles and make
`SurfacePoolWayland` manage `wl_buffer`s (in the form of SHM- or
DMABuf buffers). This will allow us to share buffers (especially
depth buffers) more efficiently, reducing VRAM usage and allocation
times.
Apart from that it will also simplify our tile management logic.
Most importantly, we'll need to reorder `wl_surface`s less often and
less complex (no `place_below` the parent surface) and can also drop
reattaching subsurfaces to compositors. Especially the former will
likely decrease CPU time in compositors.
Overall this patch makes `NativeLayerWayland` behave more like
`NativeLayerCA` while taking in lessons learned from
`WindowSurfaceWaylandMB`.
Differential Revision: https://phabricator.services.mozilla.com/D119993
Make the vsync source request frame callbacks from opaque native
layers. This is necessary as opaque layers may occlude the
MozContainer surface, which is normally used for frame callbacks.
Wayland compositors may (and are encouraged to) optimize away
such callbacks, so we need to make sure to request frame callbacks
from actually visible surfaces.
Callbacks are requested for all layers, but only the first callback
will trigger the vsync source.
In order to get this right concerning multiple requested callbacks,
possibly being called from different threads etc., introduce a
callback abstraction, `CallbackMultiplexHelper`, to make this simple
to handle for callers.
Differential Revision: https://phabricator.services.mozilla.com/D116026
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
This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Differential Revision: https://phabricator.services.mozilla.com/D89864
This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Depends on D89863
Differential Revision: https://phabricator.services.mozilla.com/D89864
This moves the clipping responsibility into the layer. It also brings back
assertions that make sure that no invalid content reaches the screen.
On the layer side I'm renaming validRect to displayRect, because at the time
NextSurface* is called, that rect is not yet valid.
This implementation also allows having valid content outside of the display
rect. So, for example, if you grow and shrink the display rect multiple times
but most of the outer parts are transparent, in theory this allows you to paint
the transparent pixels only once rather than every time the display rect
expands.
Differential Revision: https://phabricator.services.mozilla.com/D79842
For Draw (non-native) and CA modes, we include the per-tile
valid rect in the clip rect from the surface.
For DC (non-virtual) mode, a per-tile clip rect is set on the
visual for each tile, separate from the overall clip rect that
is set on the surface visual.
For DC (virtual) mode, the Trim API is used to remove pixels
in the virtual tile area that are outside the valid / clipped
region.
Note: Although the valid rect is now applied in the native
compositors, it's currently only based on the overall picture
cache bounding rect. Thus, with this patch there isn't any
noticeable performance improvement. Once this lands and is
working correctly, the follow up patch to calculate a smaller
valid region per-tile is a small amount of work.
Differential Revision: https://phabricator.services.mozilla.com/D61424
--HG--
extra : moz-landing-system : lando
Suggestions for a better name than "snapshotter" are welcome.
This is a separate object so that the lifetime of its GLContext isn't governed by the lifetime of the NativeLayerRootCA.
The NativeLayerRootCA gets destroyed on the main thread, but GLContext uses non-threadsafe weak pointer support, so it wants to be destroyed on the same thread that it was created on.
So now the GLContext lives on the snapshotter, which is created and destroyed on the renderer thread.
Differential Revision: https://phabricator.services.mozilla.com/D57068
--HG--
extra : moz-landing-system : lando
There are multiple SurfacePools: Main thread painting and the non-WebRender compositors create a new pool per window, and WebRender creates one shared pool across all windows. The non-WebRender users set the pool size limit to zero, i.e. no recycling across paints. This preserves the pre-existing behavior.
WebRender's pool size is configurable with the gfx.webrender.compositor.surface-pool-size pref.
Every window holds on to a SurfacePoolHandle. A SurfacePoolHandle has an owning reference to the pool, via a surface pool wrapper. Once all handles are gone, the surface pool goes away, too.
The SurfacePool holds on to IOSurfaces and MozFramebuffers. Both are created on demand, independently, but are associated with each other.
A given NativeLayer uses only one surface pool handle during its lifetime. The native layer no longer influences which GLContext its framebuffers are created for; the GL context is now managed by the surface pool handle.
As a result, a NativeLayer can no longer change which GLContext its framebuffers are created by.
So in the future, if we ever need to migrate a window frome one GLContext to another, we will need to recreate the NativeLayers inside it. I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D54859
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
This allows us to somewhat cheaply swap out the entire set of layers.
It also means that clearing the array of layers no longer has quadratic complexity;
in the past, you would do this by calling RemoveLayer once per layer, and RemoveLayer
does a linear scan through the array.
Differential Revision: https://phabricator.services.mozilla.com/D50725
--HG--
extra : moz-landing-system : lando
This allows us to somewhat cheaply swap out the entire set of layers.
It also means that clearing the array of layers no longer has quadratic complexity;
in the past, you would do this by calling RemoveLayer once per layer, and RemoveLayer
does a linear scan through the array.
Differential Revision: https://phabricator.services.mozilla.com/D50725
--HG--
extra : moz-landing-system : lando
This change makes opaqueness a boolean per layer again. The opaque region is
currently only used by the temporary WebRender code; the future WebRender code
won't use it. Removing this support simplifies the code and makes it easier to
implement clipping.
Differential Revision: https://phabricator.services.mozilla.com/D50722
--HG--
extra : moz-landing-system : lando
This returns the raw framebuffer GLuint and lets the caller bind it.
Initially I wanted to return a RefPtr<MozFramebuffer>, but then I discovered
that MozFramebuffer is not a refcounted class and prefers UniquePtrs.
Depends on D44324
Differential Revision: https://phabricator.services.mozilla.com/D44325
--HG--
extra : moz-landing-system : lando
This uses MacIOSurface internally. NextSurfaceAsDrawTarget locks the MacIOSurface,
and NotifySurfaceReady unlocks it if necessary.
Depends on D44321
Differential Revision: https://phabricator.services.mozilla.com/D44322
--HG--
extra : moz-landing-system : lando
The comments above these methods refer to NextSurface* methods which will be
added in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D44321
--HG--
extra : moz-landing-system : lando
NativeLayerRoot and NativeLayer allow building up a flat layer "tree" of sibling
layers. They're created and manipulated with a synchronous-looking API, but any
changes will only be applied to the underlying native layers when ApplyChanges()
is called. This ensures that the modifications can be limited to run within a
CoreAnimation transaction, and on a thread of the caller's choosing.
In the near future I'm planning to have LayerManagerComposite create these
layers. That's the reason for the pseudo-abstracted cross-platform C++ API:
LayerManagerComposite can create and place the layers, and any painting into the
layer surfaces will happen in the compositor implementations with platform-specific
code.
For now, the CoreAnimation implementation is the only implementation. I think
the current API will let us use the same infrastructure for DirectComposite
layers on Windows, but we'll likely need to make some API modifications once we
attempt that.
The classes are threadsafe; their methods can be called on any thread and the
caller is responsible for sufficient synchronization. In reality, there are only
two threads that would have a reason to use these layers: The compositor thread
and the main thread. The main thread creates and destroys the NativeLayerRootCA,
and sometimes it calls ApplyChanges, e.g. during window resizes. It also calls
SetBackingScale. All other methods are usually only called on the compositor
thread.
Differential Revision: https://phabricator.services.mozilla.com/D26407
--HG--
extra : moz-landing-system : lando
Brad Werth
Molnar Sandor
criss
Robert Mader
Markus Stange
Mihai Alexandru Michis
Narcis Beleuzu
Matt Woodrow
Simon Giesecke
Glenn Watson
Markus Stange
Cosmin Sabou
Bogdan Tara