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>
|
2022-04-20 09:32:08 +00:00
|
|
|
#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;
|
2022-02-21 10:04:36 +00:00
|
|
|
# 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
|
2022-02-21 10:04:36 +00:00
|
|
|
# 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
|
|
|
|
|
2021-08-11 07:48:53 +00:00
|
|
|
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"),
|
2021-08-11 07:48:53 +00:00
|
|
|
mWindow(std::move(aWindow)),
|
2021-07-21 20:34:55 +00:00
|
|
|
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(
|
2021-07-21 20:34:55 +00:00
|
|
|
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
|
2021-07-21 20:34:55 +00:00
|
|
|
gfx::IntRect lockRect = aInvalidRegion.GetBounds().ToUnknownRect();
|
2022-02-21 10:04:36 +00:00
|
|
|
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
|
|
|
|
|
2021-07-21 20:34:55 +00:00
|
|
|
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;
|
|
|
|
}
|
2021-07-21 20:34:55 +00:00
|
|
|
mFrameInProcess = true;
|
|
|
|
|
|
|
|
CollectPendingSurfaces(lock);
|
|
|
|
|
|
|
|
LayoutDeviceIntSize newMozContainerSize = mWindow->GetMozContainerSize();
|
|
|
|
if (mMozContainerSize != newMozContainerSize) {
|
|
|
|
mMozContainerSize = newMozContainerSize;
|
2022-02-21 10:04:36 +00:00
|
|
|
LOGWAYLAND(" new MozContainer size [%d x %d]", mMozContainerSize.width,
|
|
|
|
mMozContainerSize.height);
|
2021-07-21 20:34:55 +00:00
|
|
|
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
|
|
|
|
2021-07-21 20:34:55 +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(
|
2021-07-12 10:55:07 +00:00
|
|
|
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;
|
2021-07-21 20:34:55 +00:00
|
|
|
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 {
|
2021-07-21 20:34:55 +00:00
|
|
|
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(
|
2021-07-21 20:34:55 +00:00
|
|
|
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();
|
2021-07-21 20:34:55 +00:00
|
|
|
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);
|
2021-07-21 20:34:55 +00:00
|
|
|
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
|
|
|
|
2021-07-21 20:34:55 +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(
|
2022-02-21 10:04:36 +00:00
|
|
|
"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
|
|
|
|
|
2021-07-21 20:34:55 +00:00
|
|
|
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;
|
|
|
|
}
|
2021-07-21 20:34:55 +00:00
|
|
|
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(
|
2022-02-21 10:04:36 +00:00
|
|
|
"WindowSurfaceWaylandMB::Commit [%p] frame queued: can't lock "
|
|
|
|
"wl_surface\n",
|
|
|
|
(void*)mWindow.get());
|
2021-07-21 20:34:55 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2021-10-04 20:03:12 +00:00
|
|
|
if (moz_container_wayland_is_commiting_to_parent(container)) {
|
2022-02-23 13:17:51 +00:00
|
|
|
// When committing to parent surface we must use wl_surface_damage().
|
2021-10-04 20:03:12 +00:00
|
|
|
// 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
|
|
|
}
|
|
|
|
|
2021-08-11 07:48:52 +00:00
|
|
|
moz_container_wayland_set_scale_factor_locked(container);
|
2021-07-21 20:34:55 +00:00
|
|
|
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);
|
|
|
|
|
2021-07-21 20:34:55 +00:00
|
|
|
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
|
|
|
|
2021-07-21 20:34:55 +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
|
|
|
|
2021-07-21 20:34:55 +00:00
|
|
|
if (wl_display_flush(WaylandDisplayGet()->GetDisplay()) == -1) {
|
2022-02-21 10:04:36 +00:00
|
|
|
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(
|
2021-07-21 20:34:55 +00:00
|
|
|
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();
|
2021-07-21 20:34:55 +00:00
|
|
|
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
|
|
|
}
|
2021-07-21 20:34:55 +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);
|
2021-07-21 20:34:55 +00:00
|
|
|
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) {
|
2021-07-21 20:34:55 +00:00
|
|
|
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
|
|
|
}
|
2021-07-21 20:34:55 +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
|
|
|
}
|
|
|
|
|
2021-07-21 20:34:55 +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
|
|
|
|
2021-07-21 20:34:55 +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
|
|
|
}
|
2021-07-21 20:34:55 +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
|
|
|
}
|
|
|
|
|
2021-07-21 20:34:55 +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) {
|
2021-07-21 20:34:55 +00:00
|
|
|
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) {
|
2021-07-21 20:34:55 +00:00
|
|
|
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) {
|
2021-07-21 20:34:55 +00:00
|
|
|
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
|