I use a 3rd party tool that includes a number of editor windows and custom inspectors. I’ve found that any time one of those windows is open, or the inspector is displayed, my CPU usage skyrockets, even when the window is doing nothing but sitting there.
If I profile this in the editor, I see that every frame, the editor windows and inspectors are repainting.
This used to be a similar problem with ProBuilder’s editor window, through in a recent update they appear to have fixed it.
I’m curious if there’s a general issue/feature with UGUI, where it has to do a full repaint every frame, and there’s no way to avoid that? If an editor window’s UI is fairly complex, how do you avoid a huge performance hit every frame on repaint? My theory is that ProBuilder perhaps moved over to the new UI toolkit, which maybe doesn’t have this issue?
I’m just trying to understand the way complex editors are written, and if there’s a way to avoid this kind of thing by more selectively repainting?
Here are a couple of Profile screenshots of the Inspector and Editor window, just to give an idea of the kind of stuff I’m seeing.
It’s even worse. Put a Debug.Log() into a custom drawer class, and you will find that every frame will give all those drawers half a dozen OnGUI calls or more, so that they can calculate the layout and then draw the layout, and probably doing fresh serialization of all that stuff each time.
The inspector/IMGUI windows should only repaint when required, such as when your mouse moves over the window or a serialised value has changed.
Unfortunately there’s plenty of custom drawers out there that inadvertenly cause a repaint (or multiple) every frame, causing this high resource usage. Probuilder likely fixed this by figuring out what was causing the constant repaints and fixing it.
Seems like you ought to bring this to the attention of the people/person behind this CutsceneEditor tool.
That’s interesting, because that’s exactly what one of the ProBuilder devs said when I reported the issue to them, despite the UI definitely repainting every frame. Unfortunately, I don’t know whether they fixed this by finding a specific culprit, or by jumping ship to the new UI framework. (They had indicated they’d be migrating their UI over in the near future, though I still see various OnGUI, so many they really did track it down…)
I’ve brought it up a couple of times with the dev, but I’m not sure they’re highly motivated to research and correct the issue. I was hoping I could discover some simple reason so I could submit a better bug report to that dev. But maybe that’s a bit too optimistic.
High chance they’re still using IMGUI for their editor drawers, as are most Unity things that were IMGUI before UI Toolkit came out, and still are.
Moving over to UI toolkit is a pretty big task depending as it’d effectively require a complete rewrite from the ground up for a lot of things.
A repaint can happen or a number of reasons. The main two however are either a repaint has specifically been requested, or the value of a serialised property has changed (which really just requests a repaint).
I’ve seen a few cases where folks have written drawers that are constantly assigning values to a serialised property, which causes constant repaints. Could be the source of the problem here, could not be.
