Bug Preview animations in 2023 1 Lag (Editor FPS Drops in preview)

This issue doesn't appear in Unity 2023.2 Beta or 2022 LTS, only in 2023.1?

 

this has been tested on unity 2023.1.4f1, unity 2022.2.3.5f1 and Unity 2023.2.0b1

 

both versions seem to struggle when there is a lot of animations

 

This is a widely known problem, since at least 2019.1

Nobody at Unity seems to care.

So much so that it's getting worse as they transfer Editor UI to their all-singing, all-dancing UI Toolkit systems. Which are even slower.

That's right... a lot of this stuttering and poor performance in the Editor is from the UI updates.

Anything with a timeline and lots of values getting updated is progressively getting much worse, even on ever faster computers with better graphics cards.

 

UI Toolkit is overall substantially faster than IMGUI. However most of Unity's Editors are still written in IMGUI and are drawn via an IMGUIContainer. From looking at the C# ref, the Animation Clip preview is still written with IMGUI.

I believe IMGUI Containers have to repaint regularly for technical reasons, which ends up drawing more overhead, particularly if there's a reasonable amount of serialised data that has to be continually re-serialised. It's not a graphics related thing at that point, it becomes a memory transfer speed matter. Pure UI Toolkit editors don't have this issue thanks to the binding system.

Though this seems like something different. Like a GC allocation that's building up over time. Profiling would probably highlight the issue.

 

None of which changes the fact that the newer UI in the Editor is always slower than the older one.

It's getting so bad that the Audio Meters from AudioSources were just scrapped.

 

I haven't experienced any slowdowns myself. Again any slow downs are likely due to IMGUIContainer repaints. Because, funnily enough, it's IMGUI that's not performant.

This isn't related to this topic anyway. This is likely due to something else.

 

Good for you.

And what causes new slowdowns (the ones you're not experiencing)?

 

You're literally quoting my explanation of the slow downs. I'm not going to repeat myself.

 

IMGUI usage isn't new.

ergo... it can't be the cause of new slowdowns.

 

I said it was due to IMGUIContainer repaints, so it's a two-pronged thing. IMGUI isn't performant, particularly because IMGUI code runs multiple times within a repaint and has no state, so normally repaints are kept to a minimum to reduce overhead as much as possible. Repaints will also reserialise any Unity objects in full, again incurring overhead.

UI Toolkit is, of course, stateful, and only incurs the most overhead when initialising. The binding system avoids excessive re-serialisation as well.

Last I remember IMGUI drawn in IMGUIContainers will always be repainting if the overall visual element has focus due to whatever technical reason. We are bridging the gap between two very different worlds, after all. I think InspectorElement's are also always repainting if the drawer uses IMGUI.

So it's a bit of both. Complicated IMGUI drawers or drawers rendering lots of serialised data (or both) in an IMGUI container is likely less performant than when it was in pure IMGUI land. Though IMGUI was never particularly performant to begin with, so we're really exacerbating an already existing issue when combining it with UI toolkit.

Though UI Toolkit in a vacuum is very performant and this is quite evident in pure UI Toolkit editor windows/drawers, even very complicated ones. Dealing with large volumes of serialised data in UI toolkit is worlds more performant in my experience.

That said I can't really see an ideal solution here. UI Toolkit is much better to work with and is a necessary move forward. Our UI tooling would very much be limited otherwise, so overall it's a good thing to have UI toolkit be the base-line editor wise.

However Unity still needs to support IMGUI, hence the IMGUIContainer visual element, despite the technical setbacks it provides - which I've noted have always existed for IMGUI. More drawers will of course move to UI Toolkit overtime alleviating this.

None of this, of course, relates to OP's problem, which is likely due to something internal to the Animation Clip editor, which, as I've pointed out, is IMGUI.

 

Might look at getting unity enterprise soon, have a engineer work with me on addressing not only this issue but others as well. ill update post once i get to that point. for now, ill see if I can get my community to vote on this issue when it goes onto the bug tracker.

 

https://issuetracker.unity3d.com/is...ng-time-when-the-animation-preview-is-visible
vote on the issue, ill get my community to vote this up

 

https://issuetracker.unity3d.com/is...ng-time-when-the-animation-preview-is-visible
well its here, and vote quickly as they don't want to fix it, but since i reopened it, i can get my community to vote on this

 

Site doesn’t work.

In any case it doesn’t matter, Unity can’t code fast UIs, so what you’re asking is impossible.

 

https://issuetracker.unity3d.com/is...ng-time-when-the-animation-preview-is-visible

site works for me and mobile along with others?