diff options
| author | wm4 <wm4@nowhere> | 2014-05-17 23:59:27 +0200 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2014-05-18 00:02:55 +0200 |
| commit | 1ef1e8e509f0a5d8047a1bcaa0ae0c43ad37fe5f (patch) | |
| tree | ccc813d79426ac1f6661001433ed1e28413b64a9 /DOCS/man/en | |
| parent | c2039572b7de18d45c62f81c3d648143f22280b9 (diff) | |
| download | mpv-1ef1e8e509f0a5d8047a1bcaa0ae0c43ad37fe5f.tar.bz2 mpv-1ef1e8e509f0a5d8047a1bcaa0ae0c43ad37fe5f.tar.xz | |
client API: fix "missed" property notifications
If a property is notified as changed, and then again (before the change
notification is returned to the client), and the second change is a
sporadic change (i.e. nothing actually changed) and the change
notification was associated with with a data type, it could happen that
a change was "overlooked", because it would detect no change on the
second notification.
This is actually a pretty annoying corner case, due to the annoying way
we do things, so just store both the previously returned _and_ the newly
obtained property value. then we always compare with the user value to
check for a change, excluding any possibility of a missed change.
Note that we don't (can't/shouldn't) care if a value changes, and then
changes back; it's fine if that doesn't generate a notification. This is
due to how property notifications are supposed to be coalesced.
Diffstat (limited to 'DOCS/man/en')
0 files changed, 0 insertions, 0 deletions