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 <[email protected]> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
