Huge stall when moving undocked UI panels, especially Particle Editor

Hi. Is anyone else seeing a huge stall (e.g. 3-5 seconds) whenever moving the particle editor when it is undocked (not joined with any other UI panels)? This is occurring for us on 1.12, and doesn’t occur if another UI panel is docked to the same window (e.g. if the rollup bar is on the left of the window and the particle editor on the right).

The issue seems to effect all UI panels, however it seems to scale with the complexity of the UI, so while the particle editor stalls for up to 3-5 seconds, the material editor stalls for 1-2 seconds.

I’ve profiled the code to find the cause and it’s all within the QT library, but the difference between just the particle editor and when it is docked with another window is in the Lumberyard code (FancyDocking::dockMouseReleaseEvent).


Hi @AliBrownCIG, sorry about the UI performance issues. There are several known issues with UI performance in related to Qt UI that are most noticeable with the Particle Editor and Material Editor and we have fixes in QA review. We’ll continue looking into this and I’ll add the information about the FancyDocking slowdown. Thanks!

Hi @AliBrownCIG, I’ve uploaded a patch for you to test and posted information about it in your Lumberyard private forum. Cheers!

Any chances others can also get this patch? This “lag” is very annoying…

Sorry for necro. But the editor performance is (still?) pretty bad here, too.
It’s actually quite laggy when opening windows. (i.e. from the “Tools” Menu)

Also when clicking on entities, the right panel shows the component
details nearly a second later. This isn’t super-terrible, but a bit annoying nonetheless.

I don’t really like comparisons in threads and I really don’t like CE5. Like at all… But the editor performance is much much better there. I don’t know if it’s also based on QT but if so, there should be quite some room for improvement in LY?

(As I have worked with QT myself in the past I know that it can be quite sluggish performance wise. So I am not sure. Maybe that’s all you guys can get out of it?)

I’m just guessing but based on my experience the lag in the entity inspector is due to it doing a full update of all components and properties each time you click on a different entity. It does this a whole lot in the new landscape editor and it takes quite a while because there are lots of components that go into a single entity in the new dynamic vegetation system.

No vegetation system or anything here. Or many components on any entity for that matter.
Even when there is only the transform component attached it takes a second.
So I am not sure what happens here when there are many components on an entity. :grin:

By the way, this isn’t bound only to the main editor. It doesn’t matter where I click, the lag/delay is also in other editors, not that bad though. (i.e.: Script Canvas’ right panel lags when a different node is clicked, so does UI Editor, etc…)

There (hopefully) should be room for improvement. ( If Qt is able to deliver, that is… )
I think the LY Editor performance isn’t very good in general. But also no dealbreaker.

I wonder if CE5 uses the same backend or if it uses something else.
Clicking around there yields an instant response.

Do you know if the performance was better before UI2.0?
(Maybe it’s not yet that optimized.)

Hey @Lytz1,

Thanks very much for bringing this up. Performance in general is something we all care a lot about and I’m acutely aware of the issues with the Entity Inspector.

As @wcb mentions one of the main issues is we spend a huge amount of time constructing the elements that compose the Entity Inspector (think of the Component Cards). The way the UI refreshes is not optimal (instead of figuring out a delta of what’s changed, often the entire UI is rebuilt from scratch for every change you make).

We are aware it’s a problem and would love to find time to simplify and refactor it. Now that UI 2.0 is out there and a lot of the legacy controls have been removed, improving the underlying system will benefit all parts of the Editor. I can’t give any concrete timelines but be sure the Editor Team is aware and hopefully its something we’ll be looking at in the future.

In the meantime you could break out a copy of Very Sleepy (CPU profiler) and have a poke around to find out what’s taking all the time and open a GitHub Issue with some initial investigations. This could be a help to kick start work on improving things. You could even open a PR if you find a big win somewhere :slight_smile: (there’s undoubtably some low hanging fruit ripe for the picking in that code :stuck_out_tongue: )

I’ll make sure to bring this up with the Editor Team again and see what we can do. Thanks again for the information, these little bits of friction accumulate as you use the Editor can multiply and impact the quality of the overall experience.




Haha, alright, I might give it a shot. I also somehow completely forgot to take a look at the profiler.
Thanks for the heads up. :+1:

1 Like

No problem at all, if you do find time and find anything interesting I’d love to know! :slight_smile: Cheers!

Just a heads up:
QT6 is out today. Has some very interesting new stuff going on.
Seems like some of this might help in the future.


Qt 6.0

Qt Rendering Hardware Interface

Direct 3D, Metal, Vulkan and OpenGL. Write rendering code once, deploy to any hardware.

Qt Quick 3D

Merge 2D and 3D content with one stack.

Qt Quick Controls 2 Desktop Styling

Pixel-perfect, native looking controls seamlessly integrated into operating system.

HiDPI Support

Fractal scaling support allows for automatic UI scaling for different monitor configurations.

QProperty System

Increase code speed with binding support in C++, bringing the best part of QML to Qt with seamless integration to QObject.

Revamped Concurrency APIs

Mutiple CPUs, parallel computation, concurrency to keep your user interfaces fluent while doing backend logic in the background. Automatically scales tasks depending on the hardware.

Improved Networking Capabilities

Create your own protocol backends and integrate these into the default Qt workflow, security related features are added automatically.

Update to C++17

Update to latest standards​, with improved code readablility, better performance​ and easier maintenance.

CMake Support

Use the industry standard build system, with its wide feature set, large ecosystem to build Qt applications.

Qt for Microcontrollers (MCU)

Lightweight rendering engine to deploy QML based UIs on low-cost hardware with 2D hardware acceleration for optimal graphics performance with minimal footprint (>80KB RAM).


however, target OS specs were raised as well:

Supported in Qt 6.0


Windows 10 1809 (64 bit Intel)


macOS 10.14 and later


Embedded Linux (Yocto 3.1 Dunfell), new meta-qt6 layer

Ubuntu 20.04 (64bit Intel; gcc9)
CentOS 8.1 (64bit Intel; gcc9)
SLES 15 (SUSE Linux Enterprise Server, 64bit Intel; gcc10)
Open SUSE 15.1 (64bit; gcc9)


Android 21+


Thanks for the heads-up! :slight_smile: The Editor team have already been discussing this one :stuck_out_tongue:

1 Like