diff options
author | wm4 <wm4@nowhere> | 2019-11-28 21:19:41 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-11-29 12:14:43 +0100 |
commit | 591494b271f17c4bfae0cfb860ae12bdad98a2ca (patch) | |
tree | 90278cadcea4fb2e79a7d05ce159784f36be5361 /audio/fmt-conversion.h | |
parent | 1e6c57d4e437b403eab89d07ab61b872253b2c35 (diff) | |
download | mpv-591494b271f17c4bfae0cfb860ae12bdad98a2ca.tar.bz2 mpv-591494b271f17c4bfae0cfb860ae12bdad98a2ca.tar.xz |
m_config: add fine-grained option reporting mechanism
This adds m_config_cache_get_next_changed() and the change_flags field
in m_config_cache. Both can be used to determine whether specific
options changed (rather than the entire sub-group).
Not sure if I'm very happy with that. The former rather compact
update_options() is now a bit of a mess, because it needs to be
incremental. m_config_cache_get_next_changed() will not be too nice to
use, and change_flags still relies on global "allocation" of change
flags (see UPDATE_* defines in m_option.h). If C weren't such a
primitive language that smells like grandpa, it would be nice to define
per-option change callbacks or so.
This compares options by value to determine whether they have changed.
This makes it slower in theory, but in practice it probably doesn't
matter (options are rarely changed after initialization). The
alternative would have been per-option change counters (wastes too much
memory; not a practical problem but too ugly), or keep all
m_config_caches in a global list and have bitmaps with per-option change
bits (sounds complicated). I guess the current way is OK.
Technically, this changes semantics slightly by ignoring setting an
option to the same value. Technically this wasn't a no-op, although the
effect was almost almost no-op. Some code would actually become cleaner
by ignoring such redundant change events, and them being no-op is
probably also what the user would normally assume.
Diffstat (limited to 'audio/fmt-conversion.h')
0 files changed, 0 insertions, 0 deletions