[Bf-committers] Introduction to Notifiers

[joe]

Overzealously refreshing on notifiers is, indeed, a very, very
significant performance loss (and one I and theeth had to fix a few
weeks ago).  For example, on consumer hardware, refreshing additional
non-view3d editors when moving something in the 3d view was an extreme
problem for me (and my new, if cheap laptop); the slowest 2D editors
were the action editor, followed by the nla, the property editor, then
the graph editor.  Since in animation you may have multiple property
editors, an action editor and an nla editor open, this was a big
problem (and made blender almost unusable for me until me and theeth
fixed it).

Joe

On Fri, Feb 5, 2010 at 7:42 AM, Elia Sarti <vekoon at gmail.com> wrote:
> Hi, nice docs!
>
> Speaking of notifiers, I'd like to point out one small issue that yet
> can be annoying and probably not quick to solve. Currently UI regions
> (in most editors) are scriptified, in essence allowing people to
> edit/remove/add properties from these views (one example is rigging
> interfaces).
>
> These properties of course update correctly when you edit them from the
> UI region itself but often don't when you edit the property directly at
> the RNA level.
> This is related to how notifiers work: you have the listener for the UI
> region and this determines when to do updates but the problem is that by
> adding panels/properties to the region from py you can't really guess C
> side what updates are needed and often you end up not having properties
> update correctly.
>
> One solution could be that every property displayed in the UI region
> could make the UI region "inherit" its notifiers (those you pass to
> RNA_def_property_update) and react to those in its listener.
> The idea here is, if property "extra_info" when edited needs to send a
> NC_OBJECT|NA_EDITED notifier and I'm displaying this "extra_info"
> property, then when I see a NC_OBJECT|NA_EDITED notifier I should
> refresh the view because it is *likely* that the edited property was
> indeed "extra_info". I know this sounds bad and indeed it is, also from
> a performance stand point, because it's too generic, but would be
> automatic at least.
>
> In this case in fact I don't think py listeners really are a solution,
> as these should be specified for each panel which it's not optimal.
>
> Another, probably even worse, solution could be to add some type of
> "update hook" to RNA where basically you can add a handler for when
> properties pertaining to a certain ID or ID type are edited and act
> consequently.
>
> I understand this is not a big issue right now which is why I never
> thought of bringing it up. Although it could be annoying in some cases.
> For instance if you have a rigging interface with a property in the UI
> that represents the local position of a bone control, moving the slider
> should update the bone's position but also moving the bone should update
> the slider as expected.
>
>
> Matt Ebb wrote, on 02/05/2010 12:48 PM:
>> Hi all,
>>
>> I've noticed in IRC over the past months, a little confusion about
>> what notifiers are and how they work in Blender 2.5. I've
>> compiled/written up a little tutorial that hopefully explains their
>> purpose a bit better for new coders.
>>
>> Check it here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersIntroduction
>>
>> (Or any corrections, please edit the page :)
>>
>> As I was doing a bit of work in the wiki I also noticed a
>> not-very-widely publicised doc on adding new properties with DNA and
>> RNA. I'd encourage people unfamiliar with it to take a look:
>>
>> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DefineProperty
>>
>>
>> cheers,
>>
>> Matt
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>