Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most UI applications are broken real-time applications

thelig.ht

Post reply on HN
Print view View original

11–20 of 151 posts

Re: Most UI applications are broken real-time applications

#11

Post by cobbal »

tantalor wrote: post #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.

In my experience, "Correct" means "satisfies a specification". The specification is often about the final result, but it's not limited to it.

Re: Most UI applications are broken real-time applications

#12

Post by masfuerte »

TacticalCoder wrote: post #5
smokel wrote: post #2

I 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 percent…

Not just that. You hit a key and the game could react in literally the next frame. There was an immediacy you don't get now.

Re: Most UI applications are broken real-time applications

#13

Post by cobbal »

cobbal wrote: post #11
tantalor wrote: post #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.

In my experience, "Correct" means "satisfies a specification". The specification is often about the final result, but it's not limited to it.

As an example, I would call a function called "mergeSort" that takes O(n^2) time incorrect.

Re: Most UI applications are broken real-time applications

#14

Post by rcme »

clumsysmurf wrote: post #10

If 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 composab…

Yes, these frameworks are fundamentally broken. Even a framework with extensive usage like React doesn’t work for real-time applications. Or at least your only option is to manipulate the DOM directly for the performant real time parts.

Re: Most UI applications are broken real-time applications

#15

Post by devwastaken »

smokel wrote: post #2

I 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…

At 14 I discovered that tiny response times are essential by observing terminal echos from a TCP client and server connection. I could clearly see a 50ms difference, down to about 15ms if I recall correctly. It wasn't until years later that I discvered high response+refresh monitors and from then on anything under 120FPS is just laggy if it's a game.

Re: Most UI applications are broken real-time applications

#16

Post by PaulKeeble »

masfuerte wrote: post #12
TacticalCoder wrote: post #5

Earlier quoted context omitted.

> 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 percent…

Not just that. You hit a key and the game could react in literally the next frame. There was an immediacy you don't get now.

Ever since the xbox360 era of games the game world has been updating in parallel with the rendering of the prior frame at the very least, that pipeline is quite commonly 3 frames long now. That is a lot of latency to get some macro concurrency.

Re: Most UI applications are broken real-time applications

#17

Post by deepspace »

valbaca wrote: post #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??

Someone has not told Microsoft | It is not as simple as that.

On some Windows machines with network-mounted drives, the File-Print-to-pdf dialog takes *minutes* to become responsive, even when all currently open files are on a local drive.

This is the kind of thing the author is talking about. The programmers of that dialog box probably just called a generic "open file dialog" library function, without researching its worst-case performance.

In turn the library writers probably blithely coded something like "check if all mounted drives are accessible", without stopping to consider the worst-case performance.

Re: Most UI applications are broken real-time applications

#18

Post by PaulKeeble »

You do not want real time systems design for a GUI, its a lot more work and it wastes the vast majority of processing power to guarantee performance. You just need to be a careful about the amount of work you do in event handlers and split off heavy or IO work and split big updates. The problem is all concurrency is a lot harder than serial and so it tends to be something that is delayed until its really necessary so a lot of "not really good enough" handlers end up causing minor annoying delays.

Re: Most UI applications are broken real-time applications

#19

Post by dllthomas »

masfuerte wrote: post #12
TacticalCoder wrote: post #5

Earlier quoted context omitted.

> 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 percent…

Not just that. You hit a key and the game could react in literally the next frame. There was an immediacy you don't get now.

Metal Slug on the PS4 was jarringly unresponsive compared to my expectations, though I'm not sure I've played it on an arcade machine in 20 years so maybe it's my memory or physiology at least partly to blame.

Re: Most UI applications are broken real-time applications

#20

Post by seanalltogether »

Even if you rebuilt the the entire OS and libraries on a separation of sync vs async code, you still come to the inevitable problem of propagating delays to the user in a predictable manner.

So I've pressed a button to load a file that's usually really fast and this time nothing happens because the async call is taking it's time. Is that being represented to the user in some meaningful way? Is the button disabled until the operation completes? Is it stuck in the down position to show I can't press it again, or does it spring back up and show a loading dialog? Is that any more clear in a real time system then it would be in a blocking situation?

The problem is not blocking vs realtime, it's about programmers not understanding all the state their code can run in, and it's not clear that a realtime system would save the user when they fall into that unknown state.

Post reply on HN