Bug 1720375 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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 it's 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).
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 it's 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 not only allow us to share buffers more efficiently but 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.

Back to Bug 1720375 Comment 0