summaryrefslogtreecommitdiffstats
path: root/player/video.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-04-10 01:33:38 +0200
committerwm4 <wm4@nowhere>2020-04-10 01:33:38 +0200
commit0c9ac5835be70ae26e4aa875e833fe2c7b3b3bf3 (patch)
tree1b1e0cb5445240bafd2985b77af8013a05c844c2 /player/video.c
parenta1771ed0d451a0af75529429fee2c370671950e4 (diff)
downloadmpv-0c9ac5835be70ae26e4aa875e833fe2c7b3b3bf3.tar.bz2
mpv-0c9ac5835be70ae26e4aa875e833fe2c7b3b3bf3.tar.xz
video: remove another redundant wakeup
The wakeup at the end of VO frame rendering seems redundant, because after rendering almost no state changes. The player core can queue a new frame once frame rendering begins, and there's a separate wakeup for this. The only thing that actually changes is in->rendering. The only thing that seems to depend on it and can trigger a wakeup is the vo_still_displaying() function. Change it so that it needs an explicit call to a new API function, so we can avoid wakeups in the common case. The vo_still_displaying() code is mostly just moved around due to locking and for avoiding forward declarations. Also a somewhat risky change (tasty new bugs).
Diffstat (limited to 'player/video.c')
-rw-r--r--player/video.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/player/video.c b/player/video.c
index bae32c3f4e..630cdeffe4 100644
--- a/player/video.c
+++ b/player/video.c
@@ -1108,8 +1108,10 @@ void write_video(struct MPContext *mpctx)
struct mp_image_params p = mpctx->next_frames[0]->params;
if (!vo->params || !mp_image_params_equal(&p, vo->params)) {
// Changing config deletes the current frame; wait until it's finished.
- if (vo_still_displaying(vo))
+ if (vo_still_displaying(vo)) {
+ vo_request_wakeup_on_done(vo);
return;
+ }
const struct vo_driver *info = mpctx->video_out->driver;
char extra[20] = {0};