Hi Matt, On Fri, Nov 26, 2010 at 12:28 AM, Matt Ebb <[email protected]> wrote: > On Thu, Nov 25, 2010 at 4:10 AM, Campbell Barton <[email protected]> wrote: >> On Wed, Nov 24, 2010 at 5:08 AM, Matt Ebb <[email protected]> wrote: > >> One possible solution is to queue unique update functions for each >> update, per ID. >> A function pointer GHash & a check/w previous comparison should make >> collecting unique functions quite fast. Then these can run at the end, >> per ID. > > Well if this is necessary, it would be great to see. I suspect the > reason this hasn't caused more problems elsewhere is that the depgraph > kind of overlaps with this behaviour and probably masks the effect for > a lot of blender data (i.e. scene objects automatically getting > updated via depgraph, regardless of update functions). Presumably this > doesn't extend fully to texture data. > > Anyway, I can try to work around this for now by making a whole bunch > of abusive property set functions to do what should really be done by > update functions but it's something that really should be fixed. > > If the purpose of RNA is to provide a unified, consistent interface to > UI, python, animation system, then it's quite a problem that changing > values via UI or python does the right thing, but via the animation > system it decides to just not run the code that it's been told to.
I'm looking into a way to make DAG_id_flush_update faster, that's probably the main culprit. Objects are slow because it actually flushes the flags each time, and materials/textures because it also loops over other data to free previews/glsl. My plan is add a generic recalc flag to ID, and only do the actual flushing delayed, as part of other updates in scene_update_tagged. Brecht. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
