Skip to content

[RFC] vout: reduce display_lock acquisition duration from the UI thread

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

This follows the discussions about the display lock in !324.

Two successive mechanisms are implemented in this MR:

  1. give display_lock priority to UI requests
  2. interrupt the clock-wait between prepare() and display() (so display early) when a priority caller is waiting for the lock (what we discussed during the workshop in December)

To show the impact of each mechanism, I measured the time required to acquire the display lock by the UI thread on resize (from vout_ChangeDisplaySize()):

expand diff
diff --git a/src/video_output/video_output.c b/src/video_output/video_output.c
index 0978e7fcd2..2e1cf80ca6 100644
--- a/src/video_output/video_output.c
+++ b/src/video_output/video_output.c
@@ -454,7 +454,10 @@ void vout_ChangeDisplaySize(vout_thread_t *vout,
     assert(!sys->dummy);
 
     /* DO NOT call this outside the vout window callbacks */
+    vlc_tick_t t = vlc_tick_now();
     vlc_mutex_lock(&sys->display_lock);
+    vlc_tick_t t2 = vlc_tick_now();
+    fprintf(stderr, "[%ld] display_lock acquired from UI thread after %ld\n", t2, t2 - t);
 
     sys->window_width = width;
     sys->window_height = height;

before

Sometimes, the display lock is acquired only after 150 or 200ms, which represents several vout loops (I was playing big_buck_bunny at 25 fps).

To guarantee that the lock is acquired before the vout thread acquire it again, I made the display lock give priority to "urgent" requests, with a mechanism similar to the one already implemented for vout_control_Hold() priority.

Some parts of the implementation might probably be rewritten to use atomics and vlc_atomic_wait(), but for simplicity I used mutexes and wait conditions.

After that, the UI thread never waits more than the end of the current vout loop:

prio_lock

Then, as discussed during the workshop, if an urgent lock request is pending, the clock-wait between prepare() and display() is interrupted (so display() is called early). Since this clock-wait represents the longest duration with display lock held, this reduces the time to acquire the mutex from the UI thread:

full

Since it's a RFC, I left printf-commits to show logs if you want to test easily.

Thank you for your time.

Merge request reports