UI Sluggish

[ryancog]

On Windows, some part of this is not really fixable as I understand. The DWM system just seems to not scale with many windows (ironic). This isn't the largest issue since it only really manifests as a very weird moonwalk when dragging the editor.

More pressing is that props page in particular, with the many controls, makes things quite sluggish when resizing, switching between pages, and when opening the editor. Profiling the config/editor open routine shows most of the time going to creating the UI, and the procedure overall is a substantial hang (particularly on macOS).

Most of this comes from implicit update operations with wxWidgets, and I believe there are ways to speed things up.

[ryancog]

Discussion on sluggish performance on Windows specifically wrt ComboBoxes and Choices
https://groups.google.com/g/wx-users/c/0QsOCki2CqY

[ryancog]

At least on macOS it seems like the majority of the time goes straight to wxWidgets Create functions for respective windows/widgets. Lazy loading might just be the only real answer to that...

There is quite a bit of time spent in PCUI::ControlBase's refreshSizeAndLayout though, specifically and unsurprisingly in its call to wxWindow::Layout(). It's called in ControlBase whenever there's a rebound or visibility change, and there also seem to be some redundant calls from controls also. The layout of PCUI stuff and how it interacts with wxWidgets is not particularly straightforward, though. I'm sure it can be optimized but it would take some trial and error I think. Part of it is that still I don't fully understand the wx system, and its behavior subtly changes between platforms.

I'm realizing what I'm describing is in debug though, and that things like ASAN are eating substantial CPU time (thanks to Objective-C memory calls are everywhere). I'll need to revisit this with a debug info'd release build... I think results will be similar, but what I have isn't reliable in any case.

Resizing is the other half of this issue. I noticed it because it's particularly bad in debug but it's still not great (props page specifically) in release. I'm not too sure there's much I can do there either. Maybe freeze the insides of the scroll win while resizing is in progress? I don't recall why it gets re-laid-out currently anyways. There's probably some redundancy there.

TL;DR lazy loading and freezing seem to be the solutions I'll end up with. There are maybe a could redundant calls, but it seems most of it is just lots of controls and lots of resizing means lots of math, and it ends up becoming slow.