Rewrite Notifier System (2.8) #53308
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#53308
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently notifiers types are hard coded, where listeners make assumptions about the content each region shows.
This fails when the contents of a window is defined by add-ons, or defined dynamically.
Typical cases are:
I'm proposing to update this system with a dynamic and more general system using the publish-subscribe pattern.
This task was prompted by manipulators not responding updates to changes elsewhere, currently there are many noticeable glitches.
Process Overview
Details
bpy.app.handlers
since it should be possible to listen to changes toIt's not well defined how granular publish/subscribe messages should be.
Challenges
Changed status to: 'Open'
Added subscribers: @ideasman42, @mont29, @dfelinto, @Sergey
Added subscriber: @JoshuaLeung
Added subscriber: @brecht
Drivers can cause a change in one datablock to update a property of any other datablock, and only the depsgraph is aware of this relation. So I think it should be involved? Just the existing depsgraph is not sufficient to replace the notifier system, since it does not cover selection. The depsgraph tagging could include selection changes on datablocks, or the depsgraph could feed into the notifier system and selection changes would feed into it separately.
Personally I've always though the depsgraph should replace the non-UI part of the notifier system, especially now that is more granular than before. But I'm not sure @Sergey agrees with this.
Listening to changes from specific datablocks is tricky. You also need to listen to when that datablock changes to another datablock, and that depends on context, selection, layers, editor settings, etc. In principle you can get faster redraws if you have two editors displaying different datablocks of the same type, and redrawing just one. In practice the complexity of getting this right may not be worth it, and I think it would be better to just handle notifiers per datablock type.
@brecht makes a good point here about involving the depsgraph more here. With the
batch_cache_dirty()
stuff that a lot of datablocks now have to do to get selections redrawn in the 3D view, it makes sense to consider just having all that type of tagging being done via the depsgraph instead of having everything doing this manually. Furthermore, IMO it makes sense to give the depsgraph dedicated opcodes for this (e.g. aDEG_OPCODE_GEOMETRY_BATCHCACHE_UPDATE
for general full update, and/orDEG_OPCODE_GEOMETRY_SELECT_UPDATE
) since we've currently got a bunch of different datatypes doing these updates in the geometry ubereval.@brecht, dependency graph should indeed replace the non-interface part, but as far as i can tell here the scope is about manipulators which are exactly part of the interface. Interface MIGHT use some tagging information from the dependency graph, but then you run really quickly into chicken-egg issues because tags flush happens after notifiers are handled.
@JoshuaLeung, from the very beginning i've kept saying that using notifier system for batch caches is a no-go solution. Not sure what is the reason why it was ignored, and guess i'd just need to go ahead and clean up the mess here.
@Sergey Whatever you do here, I just hope we get the gp branch merged before you do it :P
I wasn't sure if drivers were relavant to the discussion since IIRC drivers won't modify the original data with COW - data blocks (if we want to have the same object in different states in multiple workspaces).
I think this system is useful even without ID-datablock / viewport integration, since it can be used for manipulators and UI updates. So will focus on getting this working for now, later we can look into data-block updating.
Drivers don't modify the original data with the new depsgraph anymore I guess. Maybe we want to keep showing the modified values in the UI anyway, but that's more a design topic. Regardless, editors like the 3D view or UV editor display not just original data.
I agree this doesn't need to be tackled immediately, just wanted to give some feedback since datablocks were mentioned in the task description.
How should object properties be handled that only impact overlay information?
AFAICS these shouldn't need a depsgraph recalculation, only a redraw, so might be better handled by a notifier system.
edit: Discussed with @mont29, we agree having the 3d view manially subscribe to too many fine-grain properties is probably not worth it. We can simply have the viewport subscribe to object and object-data type changes (mesh, camera, lamp etc).
If we want later, we can make them find-grained or use some other solution.
Committed to 2.8x branch, closing.
Changed status from 'Open' to: 'Resolved'
Added subscriber: @RayMairlot