Commit Graph

4 Commits

Author SHA1 Message Date
Michel Dänzer 6779ec5bf6 xwayland: Use window pixmap as a window buffer
Assuming the same number of window buffers, this results in one less
pixmap per toplevel window, saving pixmap storage.

v2:
* Preserve xwl_window_buffer_get_available behaviour (Olivier Fourdan)
v3:
* Leave RegionEmpty call where it was in xwl_window_buffers_get_pixmap,
  so it takes effect for a newly allocated struct xwl_window_buffer.
* Consolidate xwl_window_buffer->pixmap assignment in the same place.
2024-01-10 17:31:42 +00:00
Michel Dänzer 2b577c2e3b xwayland: Drop xwl_window_buffers_recycle
Use xwl_window_buffers_dispose instead. The pixmaps will need to be
re-created anyway, so keeping around the xwl_window_buffers doesn't
buy much. And dropping this makes the next commit simpler.

Also fold xwl_window_buffer_destroy_pixmap into its only remaining
caller,  xwl_window_buffer_maybe_dispose.

v2: (Olivier Fourdan)
* Fix up indentation in xwl_window_set_window_pixmap
* Leave xwl_window_buffer_destroy_pixmap helper
2024-01-10 17:31:42 +00:00
Olivier Fourdan 58155baeac xwayland: Cleanup and remove `xwayland.h`
Now that each source and header should be in order, we can safely cleaup
the last remaining bits from the main `xwayland.h` which is not needed
anymore and can be removed.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-12-20 16:19:01 +01:00
Olivier Fourdan 1c6f875f52 xwayland: Add multiple window buffering support
Add a mechanism to create, recycle and destroy window buffers when
needed.

Typically, this adds a new `xwl_window_buffer` structure which
represents a buffer for a given Xwayland window.

Each Xwayland window has two different pools of buffers:

 - The available buffers pool:
   Those are buffers which where created previously and that have either
   not been submitted to the compositor or submitted and released.

 - The unavailable buffers pool:
   Those are typically the buffers which are being used by the
   compositor, awaiting a release.

Initially, an Xwayland window starts with both pools empty. As soon as a
new buffer is needed, it's either created (if there is none available)
or picked from the pool of available buffers.

Once submitted to the compositor, the buffer is moved to the pool of
unavailable buffers. When the corresponding `wl_buffer` is released by
the compositor, it is moved back to pool of available buffers again to
be reused when needed.

To avoid keeping too many buffers around doing nothing, a garbage
collection of older, unused buffers also takes care of disposing the
buffers being unused for some time.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-11-28 17:32:44 +01:00