flashes in the ui

[gerroon]

Blender 3.3 alpha, Sverchok 1.1.0 nightly (Github)

The UI starts flashing when I add the random num gen to the Adaptive Polygons. Please see the video.

blender_4zo6aKvlNN.mp4

Not sure if this is a random gen problem, something about the scene updates causing this it seems.

blender_WM1jTrUGxZ.mp4

Thanks

[Durman]

I think this might be a problem with scene handler. It can put the tree into infinite update loop. Can you upload the file?

[zeffii]

with post-modifiers on blender becomes unusable here. (even if the Scene object doesn't have modifiers)

[gerroon]

@Durman

Try this, I get flashing when I just open this scene.

_04062022_1312_16.zip

@zeffii

Is there a work around this? I do not remember having this issue in the past.

[zeffii]

i rarely use get_objects_data node, and i'm not sure when this post-modifiers issue was introduced

the weird thing is that even if the updating is switched off (on the node) and the Live Updating is also off on the N panel, the nodeview is still grinding to a halt. The node's attempt to acquire the current dependency graph (which it needs in order to get the mesh (post modifiers)) is a prime-suspect for this infinite-loop

if you're really stuck try to figure out the last working zip by going through the commits

branch https://github.com/nortikin/sverchok/tree/40c8f53a971d393bd104ea4aa35ea9f390ee763c and
zip https://github.com/nortikin/sverchok/archive/40c8f53a971d393bd104ea4aa35ea9f390ee763c.zip maybe.

but it might be an earlier commit..

https://github.com/nortikin/sverchok/tree/032b2440c36b1e7319c6efe6fd49c3879db3cea5 -> zip

[zeffii]

it seems we don't have a useful .blend file in the collection of tests to indicate a regression. I don't see how Random Number generator is the issue here. The View header stops blinking when we untick the post-modifiers switch on get_objects_data

[gerroon]

https://github.com/nortikin/sverchok/tree/032b2440c36b1e7319c6efe6fd49c3879db3cea5 -> zip

That still has it although flashing is not as fast.

[Durman]

The problem is in Scene handler which was introduced in 1.1.0-alpha.1. For now you can switch off the Scene Update options of the tree.

When node tree is executing it can modify a scene. When scene is modified the tree is called to execute again. To avoid infinite loop I put protection key on a node tree. So if a tree has the key the next (one) scene event is skipped.

But for some reason the execution of the tree triggers two scene events and only one of them is skipped. The reason probably in this lines:

sverchok/core/handlers.py

Lines 124 to 125 in fa455c1

	if depsgraph_need:
	sv_depsgraph = bpy.context.evaluated_depsgraph_get()

[Durman]

I see two ways of solving the issue. First simple one is to merge update_trees_scene_change handler into sv_main handler. Another is to move the calling of evaluated_depsgraph_get method from sv_main handler to somewhere else. I don't know why it is placed their. It can be expensive to call it evry trigger of the handler and can be useless because when main handler is evaluated it does not mean that trees are also evaluated.

[rendetto]

The infinite loop is still present even after #4514. And it's frustratingly erratic.
On some of my scenes it starts looping when I just open the file, on others it starts just after I stopped editing a mesh object.
Sometimes I get a message in the node editor that I should press Esc key to stop it looping, sometimes there is no message and the Esc does not affect the infinite update until I stop it by switch off the "Scene update" button or the "Live update" button.
Sometimes it does not need a scene/mesh to be edited to trigger but just a node reconnection in the tree itself.

Other scenes behave just normally x_x

Unfortunately I cannot isolate a simple case for now, because my trees are pretty complex. But the problem is still there.
I'll try to find in which commit it started misbehave and with some luck will isolate some simple case to share.

[zeffii]

ouch : /

[rendetto]

Well I'm a bit confused working with GitGUI, but here what I found:
The commit called "convert NodesUpdater to Task class" (2022-05-14 22:31:44) was the last working for me.
After that the update system does not work until commit called "fix importing problem in ugly way for now" (2022-06-01 13:24:53) where the erratic update behavior became present.
Seems it comes with merging this PR #4323

[Durman]

I have an assumption of what goes wrong. New implementation of tasks (old name is Nodes updater) got an improvement of handling multiple events. Previous version was able to handle only one event and all other events during the handling were ignored. Now all events first get into todo queue. After that time handler pops one event from the queue, marks it as current task and executes it.

sverchok/core/tasks.py

Lines 24 to 25 in 7b5548c

	_todo: set['Task']
	_current: Optional['Task']

During execution of the current task new events can arrive to the todo queue and they wont be ignored. Now the logic is that only after finishing current task next scene event will be ignored but as I said they already can be in the todo queue and the handler will continue execution by poping next event from the queue. Thus we get infinite loop.

The solution I see is to ignore all new events if the time handler already started execution of one of events in the queue. But this also will break the case when changes come from user. You can move object in a scene and a tree can read its coordinates but when you stop moving the object the last readed coordinates by the tree can be different to actual one because the time handler was buisy to handle previous data and last move was ignored.

Probably something can be done to handle this case. For example if first event was "Something was changed in a node tree" ignore all scene events. Or if first event was scene one you can add more scene events to the queue. 🤔

[Durman]

Was able to reproduce the bug with such tree

[rendetto]

Yes, I can confirm similar behavior with your setup.
The loop starts when I reopen the file or just reconnecting some of the sockets.