summaryrefslogtreecommitdiffstats
path: root/waftools
diff options
context:
space:
mode:
authorNiklas Haas <git@haasn.dev>2021-11-25 23:02:39 +0100
committerNiklas Haas <github-daiK1o@haasn.dev>2021-11-28 11:58:53 +0100
commit4991ffa859384814e687c25d25d739f9db5f9033 (patch)
treedae10404b873205373013ecb85666259d2472ade /waftools
parentc66f3b0123508d2a60987065a6ee596ff28bb36b (diff)
downloadmpv-4991ffa859384814e687c25d25d739f9db5f9033.tar.bz2
mpv-4991ffa859384814e687c25d25d739f9db5f9033.tar.xz
vo_gpu_next: implement VOCTRL_SCREENSHOT
Somewhat annoying but still relatively straightforward. There are several ways to approach this, but I settled on reusing the pl_queue as a cheap way to get access to the currently mapped frame. This saves us from having to process `vo_frame` at all, and also avoids any overhead from re-uploading the same frame twice. (However maybe there's some circumstance in which `vo_frame` needs to be queried/updated first, to get a screenshot of the correct frame? I'm not sure.) I also had the option of going with either pl_render_image() on the extract pl_frame, or just calling pl_render_image_mix directly on it. I went for the latter, because in the optimal case, this allows the rendered frame to be directly retrieved from the cache, actually entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s during playback essentially free. (Except for the download cost, obviously) It would be even neater if we could make this VOCTRL asynchronous and thereby leverage libplacebo's asynchronous download capabilities. But oh well. That will have to wait for a sufficiently rainy day. Closes #9388
Diffstat (limited to 'waftools')
0 files changed, 0 insertions, 0 deletions