Stop looping execution

[Durman]

Addressed problem description

It fixes the problem when new scene events come during execution of a previous scene event

#4510 (comment)

Also it leads to a problem that not all user scene events are handled (probably this is lesser evil)

Closes #4510

Preflight checklist

• Code changes complete.

[rendetto]

Also it leads to a problem that not all user scene events are handled (probably this is lesser evil)

What type of scene events can we expect not to be handled?

[Durman]

Like this

[rendetto]

Is that drop in the performance? It will render all my work useless if it is :/

[Durman]

No, I made a havy try to make the problem to be more visible. In fast trees the difference of cause will be much smaller but it will be (most likely).

[rendetto]

I'll compare before and after and report. I'm counting a lot on the responsiveness when editing the scene because the trees I'm working on are analysing the surface-surface continuities. It is heavy by nature but was enough responsive to make an edit and read the results adjusting the quality of contacts in realtime

[rendetto]

I did several tests with four Sverchok code snapshots including:

1. pre-1.1.0-alpha1 / live update only
2. pre-1.1.0-alpha1 / Scene handler #4299
3. 1.1.0-alpha1
4. 1.1.0-alpha2 / Fix looping of scene handler #4514
5. this PR Stop looping execution #4516

All tests are made with blender-3.1.2-win-x64.

The results will follow shortly....

[rendetto]

I tested two cases:
A. Scene Handler performance

B. Animate Layout performance (since it is another way of getting realtime tree updates when editing a scene object)

Since I know how to measure only the performance of the Animate Layout via Blenders internal "fps" counter I am just eyeballing how responsive the Scene Handler behaves in comparison to the Animate Layout.
Please share if there is a precise method for measuring the performance of all the trees altogether when using the Scene Handler.

LAST EDIT
I had to reconsider my observations because I cannot measure the Scene Handler performance by any numbers. Overall this new Sverchok version is better in terms of performance. The feel of choppiness when interacting is there but the Animate Layout does not offer much smoothness by any means. I think the choppy feel comes with the UI flicker when using the Scene Handler which is not present in Animate Layout mode.
So the only concern which persists is that the UI flickering while interacting is still there. You can see how it looks in my next post.

[rendetto]

Minor problem just found. While I was playing with your setup in Scene Handler mode I pressed Esc while editing the cube - leading the cube to reset to it's initial shape. What happened is that those ellipsoids didn't update to correspond the initial state of the cube.
Note how the header menu band in the node editor flickers while I'm editing the cube.

NotCatchingUp.mp4

[rendetto]

Got similar problem to the one above but this one is not minor.

I set up a simple spline for testing the updates, while gradually raising the samples up to 100 000. "Low" samples (about 5000-10 000) did not caused visible problems while updating/interacting.
Raising the samples to 80 000-100 000 caused the UI flicker to appear, but that's not the real issue.

As you can notice the curve drawing was stuck and not updated, even I finished editing the control polygon. Here this is easy to spot, but there are cases where it won't be so obvious and will lead to wrong results.

This is the test file I'm using. test_new_update_system.zip

NotUpdating.mp4

[zeffii]

i wonder what happens if the task system didn't do this

sverchok/core/tasks.py

Lines 131 to 135 in ed954eb

	def _report_progress(self, text: str = None):
	"""Show text in the tree editor header. If text is none the header
	returns in its initial condition"""
	if self._main_area:
	self._main_area.header_text_set(text)

[rendetto]

i wonder what happens if the task system didn't do this

The UI "flickering" disappears when raising the max_duration higher.

sverchok/core/tasks.py

Lines 42 to 45 in ed954eb

	def run(self):
	"""Run given tasks to update trees and report execution process in the
	header of a node tree editor"""
	max_duration = 0.15 # 0.15 is max timer frequency

But I cannot measure if this makes the things go faster.

Also the bigger problem stays. The trees are not updating to match the final scene changes.

NoUIFlickering.mp4

[zeffii]

@rendetto you have 100k samples evaluated, does the slowdown become progressively worse as you increase from say..100 samples to 1000 samples...2000 samples?

i realized you aren't printing 100k samples using debug print (my bad!)

[rendetto]

Yes it gets progressively worse from low to high numbers. But it's predictable thing. I use this ridiculous sampling to test how the update system will hold. So this drop in performance is not unexpected but what was unexpected is that the tree execution stops before I finished editing the control points in the viewport.

EDIT
I have some new info regarding this premature stop in tree execution.
It also seems to be connected to this "max_duration" parameter I mentioned above.
When it's set to 0.15 the premature stop in tree execution is present.
When I raised it higher (in my case to 2.15) the problem does not reproduce.

[Durman]

It's possible to switch logging level to debug mode in this case time update of a tree will be printed in the console. But this does not work for animation handler. I did not implement it purposely to gain better performance during animation but I did not try to measure the impact of printing something evry frame. Anyway it seems when debug mode is off the impact should be nearly nothing 🤔

I tried to compare the performance, not without difficulties, and it was surprising that Scene handler showed x1.5 speedup compare to animation handler. It might be related with garbage collector which is switched off during work of the Scene handler. Also the measurement can be inaccurate. Something could happen outside of the measured domain.

The flickering is related with how showing of the progress work. When a node tree is light we does not show any progress because it is close to instant. But when execution time is slower then 0.15 sec the progress is starting to display. But in current case it is shown and it is instantly disappears because the rest nodes do their work pretty quick. To increase the 0.15 value means that it will be more difficult to stop tree execution because it's possible to do only inbetween of that period.

This is how tasks currently work (scene events).

-------------------------------------------------------------------------------------------------> time line
start execution of a tree ------------------------------------------> finish  .....   start -----------
  added               ignored                            ignored                      added
    ^                     ^                                 ^                           ^
    |                     |                                 |                           |
  scene                 scene                             scene                       scene
 trigger               trigger                           trigger                     trigger
    1                     2                                 3                           4

It shows that only 1 and 4 events (user edits of the mesh) will be handled by Sverchok tree. If 2 or 3 event will be last it means that there will be a difference with actual object position and last position which were read by Sverchok. I don't see elegant solution to fix this now. Probably we have to force users to do extra work by pressing select mause button or going into object mode to update final position properly for now. We have similar solution of pressing left and right arrow buttons to force node tree update.

[rendetto]

It's possible to switch logging level to debug mode in this case time update of a tree will be printed in the console

Thanks! I was able to measure ~150ms for a particular tree I'm testing currently in Scene Handler mode.
For the same tree the Animate Layout is counting ~5.50fps which should be about 180ms if I'm not mistaken (I guess this means somewhat slower).
Anyhow the performance is definitely better than before (and even better with Blender-3.2.0 which I'm testing right now).

To increase the 0.15 value means that it will be more difficult to stop tree execution because it's possible to do only inbetween of that period.

I guess for my particular process higher number works better despite it will make it hard to stop the tree execution.

Probably we have to force users to do extra work by pressing select mause button or going into object mode to update final position properly for now. We have similar solution of pressing left and right arrow buttons to force node tree update.

Because I need to read a parameter while I'm editing the mesh it is not an option for me to nudge arrow keys to re-update the trees after I finished the editing. I will just raise "max_duration" from the code knowing what it will do, which is perfectly fine for me.

I don't see elegant solution to fix this now.

@Durman Can I propose a straight approach - for the newcomer who doesn't know of those effects it could be useful to have access to "max_duration" as a global parameter in the UI. Maybe somewhere here with the appropriate tooltip:

[Durman]

Can I propose a straight approach - for the newcomer who doesn't know of those effects it could be useful to have access to "max_duration" as a global parameter in the UI.

I think what you need is uncancellable mode because changing of the max duration variable does not fix the problem. It just make the problem to appear on heavier trees (unless the value is upper big).

In uncancellable mode the scene handler should behave similar to how animation handler currently works.

Probably I can code something like this:

max_duration = 10 if self.current.is_scene_update else 0.15

It will make havy trees a bit unsafe but it still will be possible to cancel their execution after 10 seconds (probably it can be less, 5 seconds?).

[Durman]

It seems now the scene handler works more pleasant.

[rendetto]

It will make havy trees a bit unsafe but it still will be possible to cancel their execution after 10 seconds (probably it can be less, 5 seconds?).

I guess 10s is reasonable time to cancel the execution.

It seems now the scene handler works more pleasant.

Yes it is. I tested several different setups with heavy calculations and it works without problems. Thank you @Durman!

[Durman]

@rendetto Thanks for the idea =)