3 ms·

Any UI code running on a modern CPU should take close to 0ms to update, no matter how many buttons, toggles, sliders and shadows. For the rendering part, it de

Any UI code running on a modern CPU should take close to 0ms to update, no matter how many buttons, toggles, sliders and shadows. For the rendering part, it depends, I'd say it should take between 0.5 and 2ms with many layers, a lot or transparency and not much care for optimization.

gnlrtntv 4y ago
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.
kevingadd 4y ago
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.
- saagarjha 4y ago
  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.
  - kevingadd 4y ago
    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.)
  - stephc_int13 4y ago
    No, I am talking about real UI update and rendering, with all the complications, bells and whistles.
- int_19h 4y ago
  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.
  - stephc_int13 4y ago
    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.
gilgoomesh 4y ago
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.

gnlrtntv 4y ago

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.

kevingadd 4y ago

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.

saagarjha 4y ago
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.
- kevingadd 4y ago
  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.)
- stephc_int13 4y ago
  No, I am talking about real UI update and rendering, with all the complications, bells and whistles.
int_19h 4y ago
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.
- stephc_int13 4y ago
  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.

gilgoomesh 4y ago

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.