gecko-dev/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

386 lines
13 KiB
C++
Raw Normal View History

Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*-
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#include "WindowSurfaceWaylandMultiBuffer.h"
#include <errno.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <prenv.h>
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
#include "gfx2DGlue.h"
#include "gfxPlatform.h"
#include "MozContainer.h"
#include "mozilla/gfx/DataSurfaceHelpers.h"
#include "mozilla/gfx/Tools.h"
#include "mozilla/ScopeExit.h"
#include "mozilla/StaticPrefs_widget.h"
#include "mozilla/WidgetUtils.h"
#undef LOG
#ifdef MOZ_LOGGING
# include "mozilla/Logging.h"
# include "Units.h"
extern mozilla::LazyLogModule gWidgetWaylandLog;
# define LOGWAYLAND(...) \
MOZ_LOG(gWidgetWaylandLog, mozilla::LogLevel::Debug, (__VA_ARGS__))
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
#else
# define LOGWAYLAND(...)
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
#endif /* MOZ_LOGGING */
namespace mozilla::widget {
/*
Wayland multi-thread rendering scheme
Every rendering thread (main thread, compositor thread) contains its own
nsWaylandDisplay object connected to Wayland compositor (Mutter, Weston, etc.)
WindowSurfaceWayland implements WindowSurface class and draws nsWindow by
WindowSurface interface (Lock, Commit) to screen through nsWaylandDisplay.
----------------------
| Wayland compositor |
----------------------
^
|
----------------------
| nsWaylandDisplay |
----------------------
^ ^
| |
| |
| --------------------------------- ------------------
| | WindowSurfaceWayland |<------>| nsWindow |
| | | ------------------
| | ----------------------- |
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
| | | WaylandBufferSHM | |
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
| | | | |
| | | ------------------- | |
| | | | WaylandShmPool | | |
| | | ------------------- | |
| | ----------------------- |
| | |
| | ----------------------- |
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
| | | WaylandBufferSHM | |
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
| | | | |
| | | ------------------- | |
| | | | WaylandShmPool | | |
| | | ------------------- | |
| | ----------------------- |
| ---------------------------------
|
|
--------------------------------- ------------------
| WindowSurfaceWayland |<------>| nsWindow |
| | ------------------
| ----------------------- |
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
| | WaylandBufferSHM | |
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
| | | |
| | ------------------- | |
| | | WaylandShmPool | | |
| | ------------------- | |
| ----------------------- |
| |
| ----------------------- |
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
| | WaylandBufferSHM | |
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
| | | |
| | ------------------- | |
| | | WaylandShmPool | | |
| | ------------------- | |
| ----------------------- |
---------------------------------
nsWaylandDisplay
Is our connection to Wayland display server,
holds our display connection (wl_display) and event queue (wl_event_queue).
nsWaylandDisplay is created for every thread which sends data to Wayland
compositor. Wayland events for main thread is served by default Gtk+ loop,
for other threads (compositor) we must create wl_event_queue and run event loop.
WindowSurfaceWayland
Is a Wayland implementation of WindowSurface class for WindowSurfaceProvider,
we implement Lock() and Commit() interfaces from WindowSurface
for actual drawing.
One WindowSurfaceWayland draws one nsWindow so those are tied 1:1.
At Wayland level it holds one wl_surface object.
To perform visualiation of nsWindow, WindowSurfaceWayland contains one
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
wl_surface and two wl_buffer objects (owned by WaylandBufferSHM)
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
as we use double buffering. When nsWindow drawing is finished to wl_buffer,
the wl_buffer is attached to wl_surface and it's sent to Wayland compositor.
When there's no wl_buffer available for drawing (all wl_buffers are locked in
compositor for instance) we store the drawing to WindowImageSurface object
and draw later when wl_buffer becomes available or discard the
WindowImageSurface cache when whole screen is invalidated.
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
WaylandBufferSHM
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
Is a class which provides a wl_buffer for drawing.
Wl_buffer is a main Wayland object with actual graphics data.
Wl_buffer basically represent one complete window screen.
When double buffering is involved every window (GdkWindow for instance)
utilises two wl_buffers which are cycled. One is filed with data by application
and one is rendered by compositor.
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
WaylandBufferSHM is implemented by shared memory (shm).
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
It owns wl_buffer object, owns WaylandShmPool
(which provides the shared memory) and ties them together.
WaylandShmPool
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
WaylandShmPool acts as a manager of shared memory for WaylandBufferSHM.
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
Allocates it, holds reference to it and releases it.
We allocate shared memory (shm) by mmap(..., MAP_SHARED,...) as an interface
between us and wayland compositor. We draw our graphics data to the shm and
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
handle to wayland compositor by WaylandBufferSHM/WindowSurfaceWayland
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
(wl_buffer/wl_surface).
*/
using gfx::DataSourceSurface;
#define BACK_BUFFER_NUM 3
WindowSurfaceWaylandMB::WindowSurfaceWaylandMB(RefPtr<nsWindow> aWindow)
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
: mSurfaceLock("WindowSurfaceWayland lock"),
mWindow(std::move(aWindow)),
mFrameInProcess(false),
mCallbackRequested(false) {}
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
already_AddRefed<DrawTarget> WindowSurfaceWaylandMB::Lock(
const LayoutDeviceIntRegion& aInvalidRegion) {
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
MutexAutoLock lock(mSurfaceLock);
#ifdef MOZ_LOGGING
gfx::IntRect lockRect = aInvalidRegion.GetBounds().ToUnknownRect();
LOGWAYLAND("WindowSurfaceWaylandMB::Lock [%p] [%d,%d] -> [%d x %d] rects %d",
(void*)mWindow.get(), lockRect.x, lockRect.y, lockRect.width,
lockRect.height, aInvalidRegion.GetNumRects());
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
#endif
if (mWindow->WindowType() == eWindowType_invisible) {
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
return nullptr;
}
mFrameInProcess = true;
CollectPendingSurfaces(lock);
LayoutDeviceIntSize newMozContainerSize = mWindow->GetMozContainerSize();
if (mMozContainerSize != newMozContainerSize) {
mMozContainerSize = newMozContainerSize;
LOGWAYLAND(" new MozContainer size [%d x %d]", mMozContainerSize.width,
mMozContainerSize.height);
if (mInProgressBuffer) {
ReturnBufferToPool(lock, mInProgressBuffer);
mInProgressBuffer = nullptr;
}
if (mFrontBuffer) {
ReturnBufferToPool(lock, mFrontBuffer);
mFrontBuffer = nullptr;
}
mAvailableBuffers.Clear();
}
if (!mInProgressBuffer) {
if (mFrontBuffer && !mFrontBuffer->IsAttached()) {
mInProgressBuffer = mFrontBuffer;
} else {
mInProgressBuffer = ObtainBufferFromPool(lock, mMozContainerSize);
if (mFrontBuffer) {
HandlePartialUpdate(lock, aInvalidRegion);
ReturnBufferToPool(lock, mFrontBuffer);
}
}
mFrontBuffer = nullptr;
mFrontBufferInvalidRegion.SetEmpty();
}
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
RefPtr<DrawTarget> dt = mInProgressBuffer->Lock();
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
return dt.forget();
}
void WindowSurfaceWaylandMB::HandlePartialUpdate(
const MutexAutoLock& aProofOfLock,
const LayoutDeviceIntRegion& aInvalidRegion) {
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
LayoutDeviceIntRegion copyRegion;
if (mInProgressBuffer->GetBufferAge() == 2) {
copyRegion.Sub(mFrontBufferInvalidRegion, aInvalidRegion);
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
} else {
LayoutDeviceIntSize frontBufferSize = mFrontBuffer->GetSize();
copyRegion = LayoutDeviceIntRegion(LayoutDeviceIntRect(
0, 0, frontBufferSize.width, frontBufferSize.height));
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
copyRegion.SubOut(aInvalidRegion);
}
if (!copyRegion.IsEmpty()) {
RefPtr<DataSourceSurface> dataSourceSurface =
mozilla::gfx::CreateDataSourceSurfaceFromData(
mFrontBuffer->GetSize().ToUnknownSize(),
mFrontBuffer->GetSurfaceFormat(),
(const uint8_t*)mFrontBuffer->GetShmPool()->GetImageData(),
mFrontBuffer->GetSize().width *
BytesPerPixel(mFrontBuffer->GetSurfaceFormat()));
RefPtr<DrawTarget> dt = mInProgressBuffer->Lock();
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
for (auto iter = copyRegion.RectIter(); !iter.Done(); iter.Next()) {
LayoutDeviceIntRect r = iter.Get();
dt->CopySurface(dataSourceSurface, r.ToUnknownRect(),
gfx::IntPoint(r.x, r.y));
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
}
}
void WindowSurfaceWaylandMB::Commit(
const LayoutDeviceIntRegion& aInvalidRegion) {
MutexAutoLock lock(mSurfaceLock);
Commit(lock, aInvalidRegion);
}
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
void WindowSurfaceWaylandMB::Commit(
const MutexAutoLock& aProofOfLock,
const LayoutDeviceIntRegion& aInvalidRegion) {
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
#ifdef MOZ_LOGGING
gfx::IntRect invalidRect = aInvalidRegion.GetBounds().ToUnknownRect();
LOGWAYLAND(
"WindowSurfaceWaylandMB::Commit [%p] damage rect [%d, %d] -> [%d x %d] "
"MozContainer [%d x %d]\n",
(void*)mWindow.get(), invalidRect.x, invalidRect.y, invalidRect.width,
invalidRect.height, mMozContainerSize.width, mMozContainerSize.height);
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
#endif
if (!mInProgressBuffer) {
// invisible window
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
return;
}
mFrameInProcess = false;
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
MozContainer* container = mWindow->GetMozContainer();
wl_surface* waylandSurface = moz_container_wayland_surface_lock(container);
if (!waylandSurface) {
LOGWAYLAND(
"WindowSurfaceWaylandMB::Commit [%p] frame queued: can't lock "
"wl_surface\n",
(void*)mWindow.get());
if (!mCallbackRequested) {
RefPtr<WindowSurfaceWaylandMB> self(this);
moz_container_wayland_add_initial_draw_callback(
container, [self, aInvalidRegion]() -> void {
MutexAutoLock lock(self->mSurfaceLock);
if (!self->mFrameInProcess) {
self->Commit(lock, aInvalidRegion);
}
self->mCallbackRequested = false;
});
mCallbackRequested = true;
}
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
return;
}
if (moz_container_wayland_is_commiting_to_parent(container)) {
// When committing to parent surface we must use wl_surface_damage().
// A parent surface is created as v.3 object which does not support
// wl_surface_damage_buffer().
wl_surface_damage(waylandSurface, 0, 0, INT32_MAX, INT32_MAX);
} else {
for (auto iter = aInvalidRegion.RectIter(); !iter.Done(); iter.Next()) {
LayoutDeviceIntRect r = iter.Get();
wl_surface_damage_buffer(waylandSurface, r.x, r.y, r.width, r.height);
}
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
moz_container_wayland_set_scale_factor_locked(container);
mInProgressBuffer->AttachAndCommit(waylandSurface);
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
moz_container_wayland_surface_unlock(container, &waylandSurface);
mInProgressBuffer->ResetBufferAge();
mFrontBuffer = mInProgressBuffer;
mFrontBufferInvalidRegion = aInvalidRegion;
mInProgressBuffer = nullptr;
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
EnforcePoolSizeLimit(aProofOfLock);
IncrementBufferAge(aProofOfLock);
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
if (wl_display_flush(WaylandDisplayGet()->GetDisplay()) == -1) {
LOGWAYLAND("WindowSurfaceWaylandMB::Commit [%p] flush failed\n",
(void*)mWindow.get());
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
}
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
RefPtr<WaylandBufferSHM> WindowSurfaceWaylandMB::ObtainBufferFromPool(
const MutexAutoLock& aProofOfLock, const LayoutDeviceIntSize& aSize) {
if (!mAvailableBuffers.IsEmpty()) {
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
RefPtr<WaylandBufferSHM> buffer = mAvailableBuffers.PopLastElement();
mInUseBuffers.AppendElement(buffer);
return buffer;
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
RefPtr<WaylandBufferSHM> buffer = WaylandBufferSHM::Create(aSize);
mInUseBuffers.AppendElement(buffer);
return buffer;
}
void WindowSurfaceWaylandMB::ReturnBufferToPool(
const MutexAutoLock& aProofOfLock,
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
const RefPtr<WaylandBufferSHM>& aBuffer) {
if (aBuffer->IsAttached()) {
mPendingBuffers.AppendElement(aBuffer);
} else if (aBuffer->IsMatchingSize(mMozContainerSize)) {
mAvailableBuffers.AppendElement(aBuffer);
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
mInUseBuffers.RemoveElement(aBuffer);
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
void WindowSurfaceWaylandMB::EnforcePoolSizeLimit(
const MutexAutoLock& aProofOfLock) {
// Enforce the pool size limit, removing least-recently-used entries as
// necessary.
while (mAvailableBuffers.Length() > BACK_BUFFER_NUM) {
mAvailableBuffers.RemoveElementAt(0);
}
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
NS_WARNING_ASSERTION(mPendingBuffers.Length() < BACK_BUFFER_NUM,
"Are we leaking pending buffers?");
NS_WARNING_ASSERTION(mInUseBuffers.Length() < BACK_BUFFER_NUM,
"Are we leaking in-use buffers?");
}
void WindowSurfaceWaylandMB::CollectPendingSurfaces(
const MutexAutoLock& aProofOfLock) {
mPendingBuffers.RemoveElementsBy([&](auto& buffer) {
if (!buffer->IsAttached()) {
if (buffer->IsMatchingSize(mMozContainerSize)) {
mAvailableBuffers.AppendElement(std::move(buffer));
}
return true;
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
return false;
});
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
void WindowSurfaceWaylandMB::IncrementBufferAge(
const MutexAutoLock& aProofOfLock) {
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
for (const RefPtr<WaylandBufferSHM>& buffer : mInUseBuffers) {
buffer->IncrementBufferAge();
}
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
for (const RefPtr<WaylandBufferSHM>& buffer : mPendingBuffers) {
buffer->IncrementBufferAge();
}
Bug 1720375 - Restructure surface pool into a buffer pool,r=stransky,gfx-reviewers,lsalzman 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
2021-08-04 12:43:21 +00:00
for (const RefPtr<WaylandBufferSHM>& buffer : mAvailableBuffers) {
buffer->IncrementBufferAge();
}
Bug 1708416 - Implement n-buffering for the Wayland software backend, r=stransky In order to fully comply with the spec and work on all compositors. This is heavily inspired by `NativeLayerCA`: - Buffer are managed within a pool, similar to `SurfacePool`. This makes sure there's always a buffer available, even if the compositor holds buffers for longer than usually expected. One difference is that buffers are not shared between windows though, reducing complexity. - Partial damage is handled by blitting from the previous buffer, likely currently held by the Wayland compositor. While the spec is not completely clear whether this is legal, it strongly suggests it is - and other Wayland developers suggested it should be. This is almost identical to `NativeLayerCA::HandlePartialUpdate`, with a small optimization for the common case of double buffering, in witch case use a "damage history", inspired by the EGL partial damage support. As single or double buffering are by far the most common cases for shm-buffers, we limit this to double buffering to avoid complexity. Changes compared to the existing `WindowSurfaceWayland` include: - reduced complexity: - less code - no extra frame callbacks, avoiding extra steps like D117911 - no compositor specific modes - this solution should always produce fully correct output with minimal overhead. Note: a previous version of this patch only worked for SW-WR but not Basic and thus did not replace `WindowSurfaceWayland`. Now this patch supports both, making it possible to fully replace `WindowSurfaceWayland` Differential Revision: https://phabricator.services.mozilla.com/D118025
2021-06-17 13:19:14 +00:00
}
} // namespace mozilla::widget