forked from mozilla/gecko-dev
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 somewhat inspired by `SurfacePoolCA`, moving buffers between buckets - in use or available. The idea is to make it easy to expand this further to share a common buffer pool between multiple surfaces. It works similar to EGL buffer handling and reuses the partial damage logic in WR by implementing buffer age. Notable changes to the current implementation: - always draw directly into shm-buffer memory - no caching. - drawing is purely driven by the compositor / the VsyncSource. No frame callbacks or threads apart from buffer release callbacks. One of the goals here is to handle different compositor behaviour efficiently - if a compositor releases buffers early, we want to reuse a single buffer whenever possible. If a compositor holds buffers longer, we want to minimize the area we need to redraw to older buffers. This is archived by always using the last released buffer. The expected usual buffer age is `1` in the fast release case and `2`-`3` in the holding case. This changes buffer handling quite significantly, so propper testing is due. However, as the overall architecture is somewhat simpler than before, it may improve stability in the long term. Note: instead of replacing, this now duplicates parts of the existing backend. This is in order to keep the existing one stable and gruadually phasing it out together with the Basic compositor. Differential Revision: https://phabricator.services.mozilla.com/D114349
- Loading branch information
Showing
11 changed files
with
532 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.