diff options
author | wm4 <wm4@nowhere> | 2013-05-05 21:41:58 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2013-05-05 21:50:43 +0200 |
commit | 5e727c314e98aa77c255734f4aab5b0d1ad0fd3e (patch) | |
tree | 06d302c9096a9f59d2ab1eec552ba3add1b48bee /sub/draw_bmp.h | |
parent | ce9a854d54900d050cf1efcf26081d875223e448 (diff) | |
download | mpv-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