summaryrefslogtreecommitdiffstats
path: root/RELEASE_NOTES
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-11-28 21:19:41 +0100
committerwm4 <wm4@nowhere>2019-11-29 12:14:43 +0100
commit591494b271f17c4bfae0cfb860ae12bdad98a2ca (patch)
tree90278cadcea4fb2e79a7d05ce159784f36be5361 /RELEASE_NOTES
parent1e6c57d4e437b403eab89d07ab61b872253b2c35 (diff)
downloadmpv-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 'RELEASE_NOTES')
0 files changed, 0 insertions, 0 deletions