summaryrefslogtreecommitdiffstats
path: root/video/out
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-04-10 01:45:45 +0200
committerwm4 <wm4@nowhere>2020-04-10 01:45:45 +0200
commit6a13954d67143fb3c4ac8a4a7624c23e3ecb9a3c (patch)
treec70307d5de7cd68dcd19b71ad1a984c6fc84ba54 /video/out
parent0c9ac5835be70ae26e4aa875e833fe2c7b3b3bf3 (diff)
downloadmpv-6a13954d67143fb3c4ac8a4a7624c23e3ecb9a3c.tar.bz2
mpv-6a13954d67143fb3c4ac8a4a7624c23e3ecb9a3c.tar.xz
vo: further reduce redundant wakeups
In display-sync mode, the core doesn't need to woken up every vsync, but only every time a new actual video frame needs to be queued. So don't wake up if there are still frames to repeat. In audio-sync mode, the wakeup is simply redundant, since there's a separate timer (in->wakeup_pts) to control when to queue a new frame. I think. This finally brings the required playloop iterations down to almost the number of video frames. (As originally intended, really.) Also a fairly risky change.
Diffstat (limited to 'video/out')
-rw-r--r--video/out/vo.c8
1 files changed, 7 insertions, 1 deletions
diff --git a/video/out/vo.c b/video/out/vo.c
index e01bb055d3..2b15543a99 100644
--- a/video/out/vo.c
+++ b/video/out/vo.c
@@ -938,8 +938,14 @@ static bool render_frame(struct vo *vo)
in->rendering = true;
in->hasframe_rendered = true;
int64_t prev_drop_count = vo->in->drop_count;
+ // Can the core queue new video now? Non-display-sync uses a separate
+ // timer instead.
+ bool can_queue =
+ !in->frame_queued && in->current_frame->num_vsyncs < 1 && use_vsync;
pthread_mutex_unlock(&in->lock);
- wakeup_core(vo); // core can queue new video now
+
+ if (can_queue)
+ wakeup_core(vo);
stats_time_start(in->stats, "video-draw");