Skip to content

vout: handle resize requests from the vout thread

Romain Vimont requested to merge rom1v/vlc:async_resize into master

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:

  1. 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)

Merge request reports