Notifier system (event publish/subscribe)
AbandonedPublic

Authored by Campbell Barton (campbellbarton) on Nov 15 2017, 10:13 AM.

Details

Summary
  • Initial upload, this only works in basic case - editing a button & manipulators updates other areas that use the same properly.
  • Existing notifier system is disabled for property updates.

    This mostly works but causes some issue where properties should update the 3d view (viewport integration is currently undefined).
  • Using name "message bus" at the moment (since this is a term often use for publish-subscribe systems), helps differentiate with existing notifier system.
  • Updates viewport respond to changes in types instead of individual properties - to avoid too fine-grained subscriptions for every property.

  • Allocations could be moved into a mempool later on, currently its simple not to.
  • Struct names and API's are a bit confusing, this is more complicated then I'd like, but seems necessary at the moment if we want to have a generic message type that sSupports multiple types via polymorphic structs.

Python API example (this area is work in progress):

1import bpy
2
3handle = object()
4
5# all branches below work
6if 0:
7# To get some properties we need to prevent them being coerced into native Py types.
8subscribe_to = bpy.context.object.path_resolve("name", False)
9elif 0:
10subscribe_to = bpy.context.object.location
11else:
12# all object locations
13subscribe_to = bpy.types.Object, "location"
14
15def notify_test(*args):
16print("Notify changed!", args)
17
18bpy.msgbus.subscribe_rna(
19data=subscribe_to,
20owner=handle,
21args=(1, 2, 3),
22notify=notify_test,
23)
24
25# In general we won't need to explicitly publish, nevertheless - support it.
26bpy.msgbus.publish_rna(key=subscribe_to)
27
28# ... to clear
29# bpy.msgbus.clear_by_owner(handle)


Open Topics

  • Where to store the message-bus(s) so we can show the same scene at different times - without messages being causing updates in the wrong place.

    (having it subscribe to all properties seems unreasonable). - We could use more general subscriptions here - everything from Mesh/Camera/Lamp's for example - and ignore the properties.
  • What conventions to use for message-subscription life-times? For example - an addon may wan't to subscribe to changes to a property, even after a new file is loaded (we have this ability for bpy.app.handlers - called persistent handlers).

Diff Detail

Repository
rB Blender
Branch
TEMP-28-NOTIFY (branched from temp-blender2.8-notifiers)
Build Status
Buildable 1017
Build 1017: arc lint + arc unit

GHash/GSet changes now in master

  • Add static type for hard coded events
  • Generalize subscribe function
  • ID wrappers for RNA publish/subscribe
  • Enable existing notifier system again (replacing window/area updates is quite involved)
  • Move message bus into the window manager (easier to access)
  • Support anonymous RNA event subscriptions (not currently used)
  • Clear messages by owner when exiting regions
  • Count the number of subscribers tagged to run
  • correct typo
  • Manipulator publish/subscribe support
Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)
Campbell Barton (campbellbarton) retitled this revision from Work in progress replacement for the notifier system to Notifier system (event publish/subscribe), work-in-progress.Nov 16 2017, 12:57 PM

Overall looks good to me. Two questions though:

  1. Static messages are same as (or at least, very similar to) current notifier system right?
  2. What happens to subscriptions when the data pointers change (undo/redo, but also ID is deleted or remapped, or it's sub-data is re-allocated, etc.)?

Question 2 might not be an issue, but if I understood code correctly, the wmMsgSubscribeKey are more or less permanent in the GSet, which means this could build up to quite an amount of ghost keys? I’d imagine any undo/redo e.g. would imply UI re-subscribing with a lot of new keys, and some of the old ones stashing up? Or is the call to WM_msgbus_clear_by_owner in ED_region_do_drawenough to protect us against that?

As for your open topics:

Where to store the message-bus(s) so we can show the same scene at different times - without messages being causing updates in the wrong place.

Why not where we store the depsgraph too (i.e. workspaces)?

How to have the viewport respond to changes in properties?

Agree we do not want to subscribe to every property… but I think discussion in the design task T53308 (i.e. letting viewport draw tagging task to DEG somehow) is the way to go?

source/blender/windowmanager/message_bus/intern/wm_message_bus.c
95–96

That’s gonna make gcc grumpy in non-debug builds I bet ;)

source/blender/windowmanager/message_bus/intern/wm_message_bus_rna.c
49

Think should rather be named something like wm_msg_rna_gset_hash or something? Same for the next ones too…

source/blender/windowmanager/message_bus/intern/wm_message_bus_static.c
39

Same here re name, even if those are static… think they should not share names, and convey type of key etc. they handle?

source/blender/windowmanager/message_bus/wm_message_bus.h
78

That’s rather double linked list imho? Or did you mean 'simple linked list'? ;)

88

That’s rather double linked list imho? Or did you mean 'simple linked list'? ;)

103

That’s rather double linked list imho? Or did you mean 'simple linked list'? ;)

Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)
  • Remove workaround, seems no longer necessary
  • Explicitly register other properties with the camera group
This revision was automatically updated to reflect the committed changes.

Overall looks good to me. Two questions though:

  1. Static messages are same as (or at least, very similar to) current notifier system right?

Yep, this is more a test that multiple message types work, and to support some preset kinds of events in the future.

  1. What happens to subscriptions when the data pointers change (undo/redo, but also ID is deleted or remapped, or it's sub-data is re-allocated, etc.)?

Like the current notifier system, this will need to clear messages that use these ID's.

Question 2 might not be an issue, but if I understood code correctly, the wmMsgSubscribeKey are more or less permanent in the GSet, which means this could build up to quite an amount of ghost keys? I’d imagine any undo/redo e.g. would imply UI re-subscribing with a lot of new keys, and some of the old ones stashing up? Or is the call to WM_msgbus_clear_by_owner in ED_region_do_drawenough to protect us against that?

wmMsgSubscribeKey could be permanent, currently all are owned by their area, so clearing each redraw will re-create them.

We probably will need to clear all/most on undo redo, redrawing will re-populate.

As for your open topics:

Where to store the message-bus(s) so we can show the same scene at different times - without messages being causing updates in the wrong place.

Why not where we store the depsgraph too (i.e. workspaces)?

I put them here originally, it made it difficult to manage (init/exit) - since the workspace is BKE not WM. It requires function callbacks to properly manage. At the moment it doesn't make any difference and its easy to move them.

How to have the viewport respond to changes in properties?

Agree we do not want to subscribe to every property… but I think discussion in the design task T53308 (i.e. letting viewport draw tagging task to DEG somehow) is the way to go?

I *think* DEG can handle this. There is still the issue of simple draw options that don't currently involve the depsgraph, ed - drawing cameras "limits" - should the depsgraph be aware of this change for the purpose of redrawing?

Using this system we could avoid it by having (what I'm calling an anonymous subscriber - where the view3d can listen to property changes from all cameras). - Will ask about this in T53308.

  • Add support for removing ID's

Explicitly subscribe to button_properties type, improve camera manipulator updates

View3D: subscribe to changes to engine settings

Support for mathutils property types

Add publish RNA function

Support 'persistent' subscribers

Generalize region subscription

  • File selector, run refresh events on area
  • Transform manipulator - subscribe to changes to pivot/orientation
  • View3D: subscribe to changes to units

Split out subscription generation functions

Campbell Barton (campbellbarton) retitled this revision from Notifier system (event publish/subscribe), work-in-progress to Notifier system (event publish/subscribe).Feb 7 2018, 6:11 AM