It used to be a dependency cycle which lead to incorrect or
missed tesselation on some circumstances.
Seems to be introduced in rev41627.
This commit seems to behaving properly on simple cases,
probably could fail in some other cases, so need to be
checked further.
Discovered when was looking into:
#32034: Metaball used as render object(group) for particle will display wire only.
The instance modifier needs to access the derived mesh data of the particle parent object to create stuff on the hairs, however the dm does not exist when the particle modifier is hidden. This is a general design problem: Objects accessing another object's derived mesh data is unsafe. For now it just checks valid dm pointer and uses identity transform if NULL.
Replace pseudo-LRU approach of determining which buffer
to remove when running out of space allowed for cache
with approach which would remove the frame which is most
far away from newly added frame.
This is still a bit tricky because it's impossible to
distinguish which frame to delete in situation of:
CCCC...CC
^
it's either user wants to extend left segment of cached
frames and buffers from right segment should be removed
or he wants to join this two segments and in that case
buffers from right segment should be removed.
Would need a bit more investigation which situation
is more common in general usecase.
Additional changes:
- Cleanup some memutil files (which are familiar to cache limiter)
- 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.
That used to be a threading issue when two different operations
were allowed to access the same mask's cache. Now use lock in
BKE_mask_rasterize_layers so that should work fine now.
when specific circumstances are met.
Mainly issue was caused by checking ImBuf pointers, which used to fail
when some post-processing flags are changed. This was caused by the
fact that freeing old ImBuf and allocating new one could lead to new
ImBuf have the same pointer as previous one, which confuses cache.
There was some bad recursion introduced recently that caused crashes
when a Material node is the same material as the material itself (e.g.,
if Material.001 has a node with Material.001).
This commit attempt to correct this by keeping track of the material
at the root of the node tree, and doesn't recurse further if it
encounters it again within the nodetree.
Joshua, please review!
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.
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.
