The wl_buffers for the background surface only need to be updated when the output dimensions change. Using the fixed pool of two buffers to cache these buffers does not help, since if a new buffer is needed, it will have a different size than whatever buffers were cached. Furthermore, because the pool has fixed size, it is possible to run out of buffers if configure events arrive faster than pool buffers are marked not busy,, which can lead to protocol errors when the background surface is committed after acknowledging a new size, but without attaching a buffer that matches that size.
Without this change, one way to make Swaylock run out of buffers is to run it inside a nested instance of Sway, configured to draw a large image as the background, and then rapidly resize the nested instance until Swaylock receives several configure events in a single wl_display_dispatch() call.
emersion
commented
1 year ago
Quoting the commit message:
Without this change, one way to make Swaylock run out of buffers is to run it inside a nested instance of Sway, configured to draw a large image as the background, and then rapidly resize the nested instance until Swaylock receives several configure events in a single
wl_display_dispatch()call.This fixes https://github.com/swaywm/swaylock/issues/180 and might help with https://github.com/swaywm/swaylock/issues/282.
The new buffer allocation strategy for the background is closer to what swaybg does.