Custom Graphics slows down document even after being deleted

[27Fusion2]

I'm working on an add-in for the Manufacture workspace. Part of it involves drawing custom graphics to the viewport for every setup in the document- of which there might be several. These graphics are tied to geometry on the setups' models and have to be updated when the model changes. The only clear way of updating the graphics is by deleting the CustomGraphicsGroups and re-adding them (one for each setup). However, I've noticed that each time I do this, the time it takes for the graphics to draw increases (say 2 seconds the first time, 4 the second time, 6 the third time, etc.). I've checked to make sure I'm actually deleting the CustomGraphicsGroups and it seems I am, but my hunch is that even after being "deleted" they are still bogging down the document (the draw-time resets when closing and re-opening the document). After enough iterations it's possible for a graphical update (with lots of curves) to take 30+ seconds.

Has anyone else had this problem? At first I thought it was user error but the more I've investigated it the more I suspect it might be a Fusion bug.

[j4n.vokurka]

Hello,

maybe just a stupid question but are you properly updating the collection of setups before creating custom graphics each time? I would expect there to be unhandled memory that is stacking either on your side or the side of Fusion but without any sample code it is hard to say 🙂 

I have used custom graphics before and I have not encountered this error.

Jan

[27Fusion2]

Hey Jan,

I believe I am but maybe I am missing some fundamental understanding of Fusion/Python (fairly new to Python).

Either way I created a sample script to demonstrate the problem. It creates a custom graphics group for each BRep in the document and draws red curves to its edges (use caution when running on a document with lots of geometry).

The initial draw time (happens in CommandCreated) is what balloons out of control, meanwhile the button-controlled-refresh time remains constant.

It could definitely be something I'm doing wrong, but I have no idea what it is. Anyways if you could take a look I'd appreciate it.

Allan

[27Fusion2]

Forgot to mention this script is for the Design workspace.

[27Fusion2]

I think I replied to my post instead or your response by mistake (new to this forum). Adding this so you get dinged.

[j4n.vokurka]

Hello,

sorry to keep you waiting. Quite busy these days 🙂

I have tested the script you have sent and I can see no weird stuff going on. Every time custom graphics are created the time is more or less the same. Certainly there is no gradual increase visible. 

Either I don't understand your issue well enough or the problem has not manifested itself in this script. Even though I consider it unlikely there might other differences which cause the problem on your side. What os do you run on?

[27Fusion2]

Thanks for taking the time to review it.

Have you tried running the script multiple times back-to-back? That's where I'm getting my issue with the load time.

I hope you can reproduce the issue, otherwise I might have bigger problems.

My specs are:

Windows 10 Pro V 22H2
Processor Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz 3.60 GHz
Installed RAM 64.0 GB

Anyways I actually think I'm slowly figuring out the problem. I think it has to do with where I'm creating the graphics. Within a command, it seems it should only be within executePreview or execute. In both my sample script and my larger Add-In I'm creating graphics in commandCreated and commandInputChanged.

It was confusing me for a long time why many of the custom graphics samples I was seeing had no process for deleting them. Now I see that's something Fusion handles when the graphics are created during a preview event (so that if the command is canceled the graphics -and probably other document updates like geometry creation- can be "undone".)

I don't know how the graphics back-end works in Fusion but if there is an "undo" then I imagine there are something like multiple graphics objects who's existence/visibility are actively managed by Fusion depending on context. Maybe adding graphics during commandCreated/inputChanged buggers the system because it adds them to an un-anticipated graphical instance?

I'm still wrapping my head around all of it but I think I'm starting to understand. I'll update the thread if I get it fixed.

[27Fusion2 · Accepted solution]

I finally figured it out. In summary, it seems like the issue was where the custom graphics were being created. Creating them anywhere outside a command's execute() or preview() causes this ballooning issue. Still not sure why (best guess is it has to do with Fusion's undo/redo system).

My add-in draws graphics in the CAM workspace always, so I want to add my custom graphics on startup and documentOpened / documentActivated. The fix, which seems a bit hacky to me, was to make a new command that performs the graphics creation/updating on execute (set "command.isAutoExecute = True" to prevent a cmd dialog from opening). Then I can execute that command from my add-in anytime I want.

I can't tell you how many hours I lost troubleshooting this issue. Hopefully this someone else.

[BrianEkins]

Thanks for reporting your findings. What you've run into is the cost of a transaction. Anything you do in Fusion that changes something is transacted, which means it can be undone. When you have a command running, it bundles any changes into a single transaction. Outside of a command, every change you make is a single transaction. When you were creating the graphics outside a command and then did an undo or looked at the undo list, you'll see every call, which is typically many when doing custom graphics, is a separate undo. However, when you do the same thing within a command, all that work is combined into a single undo.

What you've figured out is the only workaround I know, but it is a very effective workaround.

Hopefully, Fusion will expose the transaction functionality directly through the API in the future, so even when you don't use a command, you'll still be able to group actions into a single undo. Other transaction functionality would also be useful.

[27Fusion2]

Brian, thanks for the additional info. Fusion's undo system has been a complete mystery to me so this is enlightening.  My graphics reference geometry in the design so I think ideally my graphics updates would be included in any transaction that modifies the geometry (a geometryChanged event  would be nice...)

Anyways I'm happy enough to have the loading issue resolved. Thanks again for the response.