Most UI applications are broken real-time applications
1–10 of 151 posts
Re: Most UI applications are broken real-time applications
#2I like this perspective.
In the demoscene days, we used to obsess over 60 Hz guaranteed framerates. Code was constantly being profiled using raster bars. Our effects might have been crappy, but all was buttery smooth.
Then someone decided it would be a good idea to create a common user interface that would work on many different framerates and resolutions, and all was lost. Or people would try for complex 3D graphics and sacrifice smoothness.
Some people tried to convince us that humans have a 150ms built-in visual processing delay, and all would be fine. This is not the case, and we are still stuck with mediocre animations. The content has improved a lot though :)
Re: Most UI applications are broken real-time applications
#3I believe I agree.
The iPhone UI must have either a realtime UI (or something pretty snappy). It responds to finger inputs in a bounded way.
Re: Most UI applications are broken real-time applications
#4As a human, I would like to be able to treat user interfaces as predictable, physical objects.
Unfortunately programs are built out of math and so I can’t usually do this.
Apple iOS actually does do a pretty good job of it, and that is a huge differentiator that I think is a large part of why iPhones feel great to use.
Re: Most UI applications are broken real-time applications
#5I like this perspective. In the demoscene days, we used to obsess over 60 Hz guaranteed framerates. Code was constantly being profiled using raster bars. Our effects might have been crappy, but all was buttery smooth. Then someone decided it would be a good idea to create a common user interface that would work on many different framerates and resolutions, and all was lost. Or people would try for complex 3D graphics…
> Code was constantly being profiled using raster bars.
For those wondering: we'd change the background color from, say, black to blue for the "physics" part, to green for the "drawing" part, to purple for the "audio rendering" part... All in the same frame, while the frame was being drawn.
So you'd see on the border of your screen (usually outside of the drawing area you'd have access to) approximately which percentage of each frame was eaten by "physics", graphics, audio etc. and how close you were to missing a frame.
And it was quite "hectic" typically these color "raster" bars would jump around quite some from one frame to another.
But yeah there was indeed something very special about having a pixel-perfect scrolling for a 2D game running precisely at the refresh rate (50 Hz or 60 Hz back then). And it wasn't just scrolling: games running on fixed hardware often had characters movement set specifically in "pixels per frame". It felt so smooth.
Something has definitely been lost when the shift to 3D games happened: even playing, say, Counter-Strike at 99 fps (was it even doing that? I don't remember) wasn't the same.
People don't understand that their 144 Hz monitor running a 3D game still doesn't convey that smoothness that my vintage arcade cab does when running an old 2D game with pixel-perfect scrolling while never skipping a frame.
Re: Most UI applications are broken real-time applications
#6> So correct UI applications cannot call any blocking function from their main threads.
Author is redefining "correct" to mean "has the property I care about, which in this case is performance".
There are many desirable distinct properties of a computer system: correctness, performance, security, etc.
"Correct" usually means something like "gives the right answer". It has nothing to do with performance.
Re: Most UI applications are broken real-time applications
#7> when I realized that most mainstream desktop UI applications were fundamentally broken.
Oh boy
> File system IO functions belong to a class of functions called blocking functions.
Hasn’t non-blocking IO been a major feature for about a decade now??
Re: Most UI applications are broken real-time applications
#8I believe I agree. The iPhone UI must have either a realtime UI (or something pretty snappy). It responds to finger inputs in a bounded way.
Dispatch queue. Android has the equivalent thing.
Re: Most UI applications are broken real-time applications
#9As a human, I would like to be able to treat user interfaces as predictable, physical objects. Unfortunately programs are built out of math and so I can’t usually do this. Apple iOS actually does do a pretty good job of it, and that is a huge differentiator that I think is a large part of why iPhones feel great to use.
Thank the dispatch queue and Xcode will yell at you if you do anything other than UI and very trivial computes on the main UI thread
Re: Most UI applications are broken real-time applications
#10If this article is true, I wonder if newer frameworks like Android's Compose are fundamentally flawed, at least when used in languages with garbage collection.
Essentially, composable can recompose with every frame, like for an animation. But, in certain circumstances, this will cause allocations for every frame.
For example, a modifier that is scoped to something like BoxScope. You can't hoist it out of the composable, it has to be in BoxScope. If that scope is animated on every frame, that modifier get re-allocated, every frame. That could be a lot of pressure on the GC.
Edit: Then again, its hard doing anything realtime in GC languages like Java / Kotlin, maybe its possible if doing 0 allocations per event.