7 ms·
Gamedev here, I've worked on UI code more than once, using both commercial engine and in-house. I consider it basically impossible to take more than 1ms on the
by stephc_int13 3y ago
Gamedev here, I've worked on UI code more than once, using both commercial engine and in-house.
I consider it basically impossible to take more than 1ms on the CPU to update+render an UI screen, even the most complex one.
As long as rendering is done on the GPU it should not be more than 2ms even on full-screen 4K.
The architecture of SwiftUI must be really weird to be slow/janky on a M1.
- h0l0cube 3y agoI’m an ex gamedev with the misfortune of having to work with a legacy SwiftUI project. SwiftUI, and Jetpack Compose on Android, are basically react-style functional dom-diffing style renderers and have all the problems that come from that. What’s worse is that often the project has to be recompiled in order to preview changes with this functions-as-UI-components philosophy
- Gibbon1 3y agoThe dom-diffing style makes me think of one of my beliefs about software. You have two styles. An active style where where when state is updated side effects happen directly inside the same call graph. And this passive disconnected spooky action at a distance where you update state and something else is supposed to/might execute side effects at some unspecified time in the future. The first way there is no magic going on. The second way it's all magic. I try to avoid writing code the second way if at all possible.
- stephc_int13 3y agoMagic is always bad in the software world.
- deleted 3y ago[deleted]
- varjag 3y agoThe words you're looking for are procedural and declarative.
- ironmagma 3y agoThe first style is the source of uncountable UI bugs. I have lost track of the number of times I’ve seen the developer forget to set a dirty bit to redraw the screen when some state changes. It’s the imperative vs. declarative model. Declarative may often be slower but it has other strengths.
- Gibbon1 3y agoDon't get me wrong. I totally understand that your way is why we don't see annoying rendering bugs anymore. We just put up with UI's that are slower than 25 year old UI's on machines that are a 100 times faster.
- h0l0cube 3y agoOn mobile it’s a trade off of rendering bugs with UI bugs. I’ve seen issues on older Android phones where Compose causes the text field to lose focus and flicker when typing if autocomplete is switched on. The workaround is to tell users to switch it off in the OS settings. And of course the latency issues are UX concerns all their own
- ironmagma 3y agoAt least with web apps, that tends to be the “Redux” style more than the “React” style causing that. Basically, lazy state management (and I mean this pathologically rather than in terms of Haskell’s ‘lazy’). The laziness comes from the business side of things, squeezing more productivity out of engineers per dollar. The declarative style doesn’t slow down web apps very much, it’s rerendering every component any time a state changes anywhere that does.
- TillE 3y agoI am similarly baffled that any GUI library could be noticeably laggy on modern hardware when you're just displaying a few hundred widgets at most. Even with ImGui, you have to draw a lot to drop below 120fps on an M1 Mac.
- saagarjha 3y agoSwiftUI is not an immediate-mode toolkit. In fact it’s the exact opposite of that.
- stephc_int13 3y agoYes, immediate mode is supposed to be slower because everything is rebuilt / rendered every frame, this is a kind of brute-force simplistic approach. A retained mode GUI could technically be much faster, even if I have yet to see one in the wild.