summaryrefslogtreecommitdiffstats
path: root/sub/draw_bmp.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-05-05 21:41:58 +0200
committerwm4 <wm4@nowhere>2013-05-05 21:50:43 +0200
commit5e727c314e98aa77c255734f4aab5b0d1ad0fd3e (patch)
tree06d302c9096a9f59d2ab1eec552ba3add1b48bee /sub/draw_bmp.h
parentce9a854d54900d050cf1efcf26081d875223e448 (diff)
downloadmpv-5e727c314e98aa77c255734f4aab5b0d1ad0fd3e.tar.bz2
mpv-5e727c314e98aa77c255734f4aab5b0d1ad0fd3e.tar.xz
stream: fix bad cache behavior introduced by recent commit
Commit 4d14a42, a seemingly harmless change, introduced very bad cache behavior when the cache isn't forked, such as on Windows, where it uses threads. Apparently the cache code was designed for forking, and an unknown obscure condition causes severe performance degradation if a STREAM_CTRL is sent to the cache on every frame. Since the cache code is literally insane (uses shared memory + fork(), and has hacks to make it work with threads, is messed into the stream code in extra-hacky ways), we just fix it by caching the STREAM_CTRL in question. This is also done for some other STREAM_CTRLs that are called on each frame, such as playback duration. This indicates that the cache code has some inherent problem with answering such requests in a timely matter, and that there's no easy way around this. (Even if the cache is eventually rewritten, these things will probably have to be cached, otherwise you'd have to forcibly block until the stream implementation is done with a blocking read. The real question is why it worked fine with the forked cache, though.)
Diffstat (limited to 'sub/draw_bmp.h')
0 files changed, 0 insertions, 0 deletions