diff options
author | wm4 <wm4@nowhere> | 2019-12-19 12:41:01 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-12-19 12:41:01 +0100 |
commit | 48f906249ef359c66fc6c5bf4cc5885c8293bf8e (patch) | |
tree | f0d31632b957211f526f8d590be19ee611828bb2 /player/command.c | |
parent | ce9d2c9f8e6645c7a0e9b216d29f4d237355ce61 (diff) | |
download | mpv-48f906249ef359c66fc6c5bf4cc5885c8293bf8e.tar.bz2 mpv-48f906249ef359c66fc6c5bf4cc5885c8293bf8e.tar.xz |
osc: use property notifications and a timer instead of "tick" events
Traditionally, the OSC used mpv's "tick" event, which was approximately
sent once per video frame. It didn't try to track any other state, and
just updated everything.
This is sort of a problem in many corner cases and non-corner cases. For
example, it would eat CPU in the paused state (probably to some degree
also the mpv core's fault), or would waste power or even throw errors
("event queue overflows") on high FPS video.
Change this to not using the tick event. Instead, react to a number of
property change events. Rate-limit actual redrawing with a timer; the
next update cannot happen sooner than the hardcoded 30ms OSC frame
duration. This has also the effect that multiple successive updates are
(mostly) coalesced.
This means the OSC won't eat your CPU when the player is fucking paused.
(It'll still update if e.g. the cache is growing, though.) There is some
potential for bugs whenever it uses properties that are not explicitly
observed. (In theory we could easily change this to a reactive concept
to avoid such things, but whatever.)
Diffstat (limited to 'player/command.c')
0 files changed, 0 insertions, 0 deletions