Workbench causes high CPU utilization when minimized with a ProVis tab open

[king-shak]

Something I've noticed is when I minimize Workbench and have a ProVis tab open (even if there is no provenance file open) is that Workbench immediately begins to hit the CPU (I experience about a 12% load), to the point where I start experiencing system-wide instability. Within minutes my system can be completely unresponsive. When I bring Workbench back up (if I can) my CPU utilization goes back down and the system becomes stable again.

This is surprising since I'm on a desktop with a fairly decent processor (Ryzen 5 5600X) and the utilization isn't even that high - I've never seen this kind of instability with my system even with much more intensive workloads. This could be a huge problem on laptops which usually don't have nearly as much power as a desktop.

I'm not sure what the issue is, other than it's something wrong with ProVis - I'll have to do some digging.

[king-shak]

It turns out the issue for this was an AnimationTimer for the ProVis tab (defined in ProVisCtrl). It's basically an event handler for when a new frame is being drawn. It seems to (1) calculate the repelling force of each node against each other, updating their positions, and (2) draw the canvas (the area where all the nodes are in the ProVis tab) which includes drawing all the nodes, their labels, the edges between them, etc.

It only does the former when the "Stop Vertices" switch in the ProVis tab is not selected, however it was doing the latter all the time. This is because if you selected "Stop Vertices" and resized your window, or minimized it and brought it back up, the canvas would be empty as it needs to be re-drawn.

So, I set an event handler for the iconified property of the application, which tells you if the application is minimized or not. It stops this timer (i.e., stops calculating new positions for the nodes and stops re-drawing the canvas) if the application is minimized, and starts it again when the application is brought back up from the taskbar.

[stiber]

So, was it just the timer, or was it drawing and re-drawing the window even if not needed? If the latter, then shouldn't this be handed off to a more "vanilla" type of window redrawing callback (for static window content) if "stop vertices" is selected?

We should probably add an issue to auto-stop the vertices at some point, as their motion slows down. Any reason not to?

[king-shak]

So, was it just the timer, or was it drawing and re-drawing the window even if not needed? If the latter, then shouldn't this be handed off to a more "vanilla" type of window redrawing callback (for static window content) if "stop vertices" is selected?

The latter. I first tried putting everything into the if statement that checks if "Stop Vertices" is selected, just to be sure, and as I expected the utilization went down when "Stop Vertices" was selected (the the timer doesn't do much).

I think we could do a lighter redrawing method, but is it necessary? At least on my system, (I can try on a laptop), even when I have some provenance open and am playing around with the nodes it's only utilizing like ~1-2% of the CPU. It doesn't seem very taxing.

It's fine when it's re-drawing and the window isn't minimized, the issue is when it's minimized, I guess because the window size is really small or just nil and it's thrown off by that.

We should probably add an issue to auto-stop the vertices at some point, as their motion slows down. Any reason not to?

I think this is good idea. Something I noticed is when you have a set of nodes or some groups of nodes (example of the latter in the image down below) is that while the nodes within the groups space out and eventually stop moving, the individual unconnected groups slowly drift away from each other over time. I guess the repelling force between them never goes to 0? Maybe we could have something where if the repelling force reaches a certain threshold you just stop moving them.

If you're curious, because I know Steven was, both of these groups represent sims ran remotely. The one with the commit node was pulled from the repo (or pointed to a directory with a git repo in it to get the commit ID - I don't exactly remember), while the other one was pointed to a directory which already contained an executable (and not git repo - thus no commit ID to grab) and was just told to run it.

Also, I guess I don't really understand the purpose of this functionality (the nodes always re-adjusting unless you stop them). Obviously it makes sense when you first load the file, as everything spaces itself out. It confuses me when I want to open a diff on two nodes, where I have to drag one node to another. If I haven't selected "Stop Vertices", the node I'm dragging towards just runs away (fun to watch), so I have to stop them, then I can drag one on top of another. But once I'm done looking at the diff, they're left sitting on top of each other. Why not instead space them out when the file is loaded, automatically stop once they've slowed down, and don't move them around when the user is trying to drag a node? Then, when they're done dragging, that node can snap back into place.

Maybe there's something I'm missing as to why it is currently set up like this, those are just some thoughts I have.

[stiber]

I guess the repelling force between them never goes to 0? Maybe we could have something where if the repelling force reaches a certain threshold you just stop moving them.

It's been a while, but I believe you are right; with no connection, there is no countervailing force. We could threshold on force or speed of motion, I think.

I guess I don't really understand the purpose of this functionality

The idea was to have the graph display self-organize. It really should stop/be stopped, once the graph display is "nice". What you write is what should happen; this is symptomatic of additional functionality being implemented on top of the basic graph display algorithm without that algorithm being modified.