In my experience working with IMGUI-style libraries, it's definitely feasible to perform full layout and rendering for complex UI in 1-2ms at most. For simpler applications it should be basically free. It's depressing that people are willing to accept complex, slow layout APIs at this point considering it's been possible for stuff to be fast for a long time.

Perhaps surprisingly, the most expensive part is usually text layout and rendering - text shaping is just really expensive and in the industry standard libraries it can take a long time to lay out a string, so you have to aggressively cache and do fancy things to get good performance. ASCII text is fast, though.

Whenever people come up with low numbers like that their mental model is really what they see as sticking some ASCII on the screen with a couple of colors blitted in. Doing text rendering that is actually good, transparency, shadows, the things that make a UI worth using makes things somewhat more expensive. It doesn't have to be overbearingly expensive–modern computers are fast, after all–but it's definitely going to be more than what you think an imgui thing is going to take. And this is pretty important when you're making an OS, otherwise you're really making something that a lot of people will not want to or be able to use.

I've been doing complex UI with a few different IMGUI libraries for years now and they can all lay out and rasterize complex scenes in under 2ms, even when written in C# instead of performance-tuned C++. Modern hardware is just plain fast, in particular drop shadows and transparency are effectively free if you're drawing them using the GPU. (I say 'effectively' because if you opt out of transparency and antialiasing, you can do front-to-back rendering to skip drawing stuff entirely... but I don't know of many cases where people do that since it's not that much faster.)

No, I am talking about real UI update and rendering, with all the complications, bells and whistles.

I don't think it's very surprising once one considers all the complications of Unicode text layout: combining marks, ligatures, right-to-left etc.

Well, text layout is not trivial. But computers are incredibly fast when dealing with small amount of data.

I don't see why all of text layout calculations could not be done at maximum speed with everything in L1. Probably with quite a few branch miss-prediction, but still.

The amount of work you can achieve in 1ms on a modern CPU is astonishing.

My intuition is that there are probably a bunch of O(NNN) complexity algorithms in typesetting for things like ligatures, and that's where the time goes... but I haven't written a shaping engine.

Even with O(n^3) algorithms, how many symbols can you put on a display?

And to be fair, more than 90% of those symbols are very likely to be plain old ASCII...

SwiftUI can be ridiculously fast – closer to a 3D framework than a typical 2D windowing framework – because it can reduce to a set of uninterrupted draw calls.

Rendering is not why SwiftUI can be slow.

If you don't know what you're doing, it's possible for SwiftUI to think your new view is unrelated to the old view and everything needs deallocation and reallocation.

The cost here is not from rendering speed — as you point out, UI rendering is so fast in most modern environments, even on a bad day, that drawing the UI itself is pretty much never the actual load that slows anything to a crawl.

Based on the author's description, it sounds like the real cost here was from way over-diffing a set of models that weren't very efficiently bound to the UI. This is a very common source of bugs in all declarative frameworks.

In SwiftUI, the consequences can be particularly bad, because there are a couple somewhat innocent-sounding ways of injecting dependencies into your UI that actually invalidate the whole thing on any value's change and cause major updates (including, if a custom "Representable" that uses its own GPU tools is not implemented carefully, potentially reallocating all kinds of buffers and drawing tools).

This is all stuff that you learn how to deal with as you get used to the framework and learn its more advanced tools, but adapting to this part is not really something there's a lot of documentation for.