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
This becomes possible as a side effect of making sure that the current
buffer content is always completely valid, by blitting from the
previous buffer, analogous to
`NativeLayerCA::HandlePartialUpdate` and
`WindowSurfaceWaylandMB::HandlePartialUpdate`.
Apart from reducing overpaint, this improves correctness is many
situations, avoiding glitches.
Note: the approach here may not be optimal concerning efficiency yet
and improvements are planed after further refactoring.
Depends on D118925
Differential Revision: https://phabricator.services.mozilla.com/D119015
Instead of using the Wayland EGL platform. The later is very convenient
but has several limitations. Managing FBOs allows to make our code more
similar to that of MacOS as well as the Wayland software backend.
Most importantly, it will allow us to cleanly implement partial damage
by giving us direct acces to previously submitted buffers, allowing us
to blit back from them, similar like in
`NativeLayerCA::HandlePartialUpdate`.
There are several other fields where more control over buffers will
come in handy, too many to describe them here in detail.
Note: we still use individual buffer pools for each tile. However, this
change brings everything into place to allow us to change to a more
`SurfacePoolCA`-style shared pool. That will reduce GPU-memory usage.
Includes some minor cleanups here and there.
Depends on D119013
Differential Revision: https://phabricator.services.mozilla.com/D118925
This becomes possible as a side effect of making sure that the current
buffer content is always completely valid, by blitting from the
previous buffer, analogous to
`NativeLayerCA::HandlePartialUpdate` and
`WindowSurfaceWaylandMB::HandlePartialUpdate`.
Apart from reducing overpaint, this improves correctness is many
situations, avoiding glitches.
Note: the approach here may not be optimal concerning efficiency yet
and improvements are planed after further refactoring.
Depends on D118925
Differential Revision: https://phabricator.services.mozilla.com/D119015
Instead of using the Wayland EGL platform. The later is very convenient
but has several limitations. Managing FBOs allows to make our code more
similar to that of MacOS as well as the Wayland software backend.
Most importantly, it will allow us to cleanly implement partial damage
by giving us direct acces to previously submitted buffers, allowing us
to blit back from them, similar like in
`NativeLayerCA::HandlePartialUpdate`.
There are several other fields where more control over buffers will
come in handy, too many to describe them here in detail.
Note: we still use individual buffer pools for each tile. However, this
change brings everything into place to allow us to change to a more
`SurfacePoolCA`-style shared pool. That will reduce GPU-memory usage.
Includes some minor cleanups here and there.
Depends on D119013
Differential Revision: https://phabricator.services.mozilla.com/D118925
Unlike buffer release callbacks, which can't happen after the
corresponding buffer was destroyed, frame callbacks can apparently
arrive even if the corresponding surface was destroyed.
This kinda makes sense as frame callbacks have independent objects
which actually can get destroyed manually.
Also wait for the lock in the destructor to not unref the surface
below our feet.
Differential Revision: https://phabricator.services.mozilla.com/D118274
This caused e.g. WebGL content to get hidden as it always fell out
of bounds. As a side effect clean up the whole custom transform math.
Differential Revision: https://phabricator.services.mozilla.com/D118288
In order to avoid system compositor and wire overhead.
Also make more internals of `NativeSurfaceWayland` private.
Depends on D116675
Differential Revision: https://phabricator.services.mozilla.com/D116721
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
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
Greg V
Robert Mader
Sandor Molnar