[vlc-devel] [PATCH v2] video_output: wait half the extra time we have without getting the display_lock

[Steve Lhomme]

Since f1bf7ce5b4480a3d38d54c7ae1d1564f0670d83f we start the rendering much
earlier than before, so we have more time to do things if necessary.

The problem is that for almost all the duration of the call display_lock is
held. So it's blocking all other UI related events from being handled. Even if
we are going to spend most of the time waiting until we can do the display.

This patch waits a bit before locking the display_lock when we estimate we will
have so extra time before doing the display/swap.

Fixes #25479
---
 src/video_output/video_output.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/src/video_output/video_output.c b/src/video_output/video_output.c
index 9881dcccd5d..ad8ee5f2dae 100644
--- a/src/video_output/video_output.c
+++ b/src/video_output/video_output.c
@@ -1119,6 +1119,33 @@ static int ThreadDisplayRenderPicture(vout_thread_sys_t *vout, bool render_now)
     if (filtered->date != sys->displayed.current->date)
         msg_Warn(&vout->obj, "Unsupported timestamp modifications done by chain_interactive");
 
+    if (!render_now)
+    {
+        vlc_tick_t now = vlc_tick_now();
+        vlc_tick_t system_pts = vlc_clock_ConvertToSystem(sys->clock, now, filtered->date, sys->rate);
+        if (unlikely(system_pts != INT64_MAX))
+        {
+            const vlc_tick_t late = now - system_pts;
+            if (unlikely(late <= 0))
+            {
+                // wait half the extra time we have without the display_lock
+                /* Work around the fact that once we have the next picture we start
+                 * the rendering right away instead of waiting for the last moment to do it.
+                 *
+                 * On Windows the deadline handling is not accurate enough, it can exit
+                 * way too late and we end up dropping the picture we were about to display.
+                 *
+                 * Here we are sure we don't miss the opportunity to display it but we
+                 * still need to leave some time without the display_lock so the UI
+                 * has a chance to send some messages.
+                 */
+                vlc_tick_t max_time_to_render = sys->render.avg;
+                vlc_clock_Wait(sys->clock, now , filtered->date - max_time_to_render / 2, sys->rate,
+                            VOUT_REDISPLAY_DELAY);
+            }
+        }
+    }
+
     vout_display_t *vd = sys->display;
 
     vlc_mutex_lock(&sys->display_lock);
-- 
2.29.2