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.
This helps keeping memory usage low and have cached segments untouched
when mixing stuff like tracking and rendering -- now you wouldn't be
need to re-cache segment you're working on after rendering.
---
svn merge -r48550:48552 ^/branches/soc-2011-tomato
All node group operators which move nodes directly between bNodeTree->nodes lists now make sure the node names are indeed unique in their new environment (the node group tree or the parent tree).
Note: This fix could cause other issues with shared physics meshes. In general, we may want to re-evaluate how we handle updating potentially shared physics meshes.
unwrapper flush the correct aspect flag to mtpoly after unwrap. Faces
that have been unwrapped with correct aspect option will fix their
aspect each time a different image is assigned to them. I hope fix works
100%, I can't say that I really understood the bizarre aspect ratio
system.
This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator.
It also adds a few getters (to get RNA i18n context, and current language iso code).
Finally, it adds to C operators needed for the py ui_translation addon:
*UI_OT_edittranslation_init, which gathers requested data and launch the py operator.
*UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files).
For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
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.
