There were some crashes discovered in some circumstances of using
color management within the clip editor which ended up some refactoring
of color management cache.
Switch from global movie cache instance to per-image buffer instances
This only means keys for color managed buffers could be much simpier
and that look up would happen much faster in there're lots of frames
cached. Memory limiter stuff is still global for all color management
and in fact it's also shared with movie clip cache .
This allowed to get rid of original image buffer stored in cache
key and allowed to easily remove all display buffers when source
image buffer is being freed. This was main culptrit leading to
crashes.
Additional changes:
- Add option to make moviecache verbose. If DEBUG_MESSAGES is
defined in moviecache.c detailed logs would be printed to the
console.
- Movie caches are now named which helps reading debug messages.
- Improved a bit behavior of cache element removing when buffer
overflows on adding new display buffer and there're frames from
movie clip.
- images that can't be loaded because of the limit are printed in the console.
- textures that can't be found show up as pink (so we know somethings wrong).
1. first pass only fast nodes are calculated and only to the active
viewer node
2. second pass all nodes to all outputs
Temp disabled highlights because of random crashes.
Forgot DNA needed stable names... :/ Correct spelling would involve keeping the old one for load code anyway, so better live with incorrect spelling here.
This creates a list of splines to be rasterized in nitExecution which
is being called from main thread. This should resolve possible threading
issues discovered in tomato branch.
movie clip caches resulting in some unchecked NULL pointers.
Probably it'll be better to separate memory limitors for cache and
clips or double-check priority functions are fine to deal with
such cases.
(From personal stash of bugs - since early 2.5 versions)
F-Curve colors get applied only on Graph Editor "refresh()". In some cases, undo
was reverting back to a state where the colors had not yet been set. In these
cases, there would be no refresh() after that undo (until expanding a channel or
some other similar action), resulting in "black F-Curves" appearing. So, now we
force such an update after undo to ensure that the curves never display black.
(Noticed while investigating another bug for Mango related to
CLIP_OT_constraint_to_fcurve not sending notifiers required when new F-Curves
are added)
* Elbeem exporter code now overrides user settings to No Slip in case the object is animated;
* UI of fluid obstacles now disables slip settings when export animated is enabled;
* Added in this later option's tooltip a mention that it enforces No Slip!
