[Bf-committers] RNA property updates vs anim sys
Brecht Van Lommel
brechtvanlommel at pandora.be
Fri Nov 26 17:37:03 CET 2010
On Fri, Nov 26, 2010 at 12:28 AM, Matt Ebb <matt at mke3.net> wrote:
> On Thu, Nov 25, 2010 at 4:10 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> On Wed, Nov 24, 2010 at 5:08 AM, Matt Ebb <matt at mke3.net> 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.
More information about the Bf-committers