vout: handle resize requests from the vout thread
Resize requests are executed from the UI thread, so they must return
"quickly". Currently, the display_lock is acquired on the vout thread
for relatively long periods (which is a problem on its own), so locking
the display_lock from the UI thread causes unacceptable freezes.
Display resizing has been made synchronous relative to the vout thread by commit c9d6d95f. The commit message mentions:
this ensures that we do not queue a large number of events via vout control upon drag-and-drop of the window.
To avoid the problem, this commit only keeps the latest resize request (overwriting any previous one).
This also prevents acknowledging the window resize before the resize is actually handled
The resize ack is now called from the vout thread, with the same guarantees as before. In particular, it implements a mechanism similar to the first alternative listed in commit 919ba1c9:
- Invoking a callback to the window provider from the video output thread code code.
Two points were mentioned:
This can delay the callback unreasonably.
Delaying the callback should not be a problem, the serial (a uint32_t
event identifier) is sent with the ack_configure request, the wayland
compositor should handle it correctly.
But anyway, the callback is called after all rendering operations using the previous window size (and before all rendering operations using the new windows size). Blocking the UI thread until this point in time does not reduce the delay.
Taking the window lock on the video output thread is undesirable if at all possible.
This callback does not require the window lock.
Fixes #25603 (closed)