summaryrefslogtreecommitdiffstats
path: root/video/out/gpu/libmpv_gpu.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2018-04-20 21:54:03 +0200
committerJan Ekström <jeebjp@gmail.com>2018-04-29 02:21:32 +0300
commit36565c099debbcfdfe800a5c2c1c9c9fada0a48b (patch)
tree8188f3fb35979df0ad739b3d764746a80c32205c /video/out/gpu/libmpv_gpu.c
parent44f00a1f5876183530bafb0fd4f5aaf088860672 (diff)
downloadmpv-36565c099debbcfdfe800a5c2c1c9c9fada0a48b.tar.bz2
mpv-36565c099debbcfdfe800a5c2c1c9c9fada0a48b.tar.xz
vo_libmpv: adjust redraw handling to new API semantics
In MPV_RENDER_PARAM_ADVANCED_CONTROL mode, a simple update callback does not necessarily make the API user redraw. So handle it differently. For one, setting vo->want_redraw already uses the "normal" redraw path, which will call draw_frame() and set next_frame. Then there are redraws trigered by mpv_render_context_set_parameter(), which are on the render thread, and would require a separate mechanism. I decided this is not really a good idea, since it's not even clear that setting an arbitrary parameter should redraw. Also this could trigger an unbounded number of redraws. The user can trigger redraws manually if really needed, depending on the parameter that's being set. If we really wanted vo_libmpv to do this, we could add a new flag like need_redraw, which would be 4 lines of code or so.
Diffstat (limited to 'video/out/gpu/libmpv_gpu.c')
0 files changed, 0 insertions, 0 deletions