Live data from Hacker News

Most UI applications are broken real-time applications

thelig.ht

101–110 of 151 posts

Re: Most UI applications are broken real-time applications

#101
Visual Studio Code has a huge realtime problem. I find myself typing ahead by ten or 15 characters most of the time before changes show up in the UI. At which point either my brain-typeahead buffer overflows, or keystrokes start getting dropped (I'm not sure which).

Not sure if this is a problem specifically on Linux or not. I like to think that on Windows, UI-thread/process priority boosts take care of this problem, but I suspect not entirely.

I've been meaning to turn off Intellisense to see if my productivity will increase. What I know for sure: my productivity in VSCode/C++ is hugely tanked compared to Android Studio/java.

Re: Most UI applications are broken real-time applications

#102
We have UI models that allow us to through long-running operations onto a background thread so that we can render perfectly animated hypno-toad cursors Or, more currently, perfectly animated cute-wait animations to keep people entertained while long-running operations complete. (Only a matter of time before wait-animations incorporate mini-games to play while while you're waiting, I think). But...

I'm not sure we have UI models for dealing with more complicated asynchronous operations on a document model though.

Old versions of Microsoft word used to run pagination and line-breaking on a background thread. The UI would keep a couple of lines around the edit cursor up-to-date, with precisely page layout for anything more than a couple of lines after the edit cursor running asynchronously. (It probably still does, but we probably notice it less these days).

And various elaborate schemes for keeping local and cloud object models synchronized asynchronously.

Oh. And I guess we have compilers and editors that collaborate to take snapshots of code when a compile starts, while allowing editing to continue, and to run Intellisense analysis in the background in the face of continually updating edit buffers. Incredibly complicated stuff, done mostly by brute force of intellect, I think.

Beyond that, I don't think we have a general theory of what to do in user interfaces when there isn't enough CPU to go around.

Re: Most UI applications are broken real-time applications

#103
post #47

I believe it's pretty easy to resolve -- declare one thread as "UI Thread", and forbid doing any IO on it. Android (and I believe iOS does too) enforce that. It's up to the developer to show a meaningful message/animation if an IO operation takes noticeable time.

Correct. Looking at the Windows side of things, most of the UWP APIs are designed to be async, meaning they will never block the UI thread.

The author is giving the OS a unfair rep here. All three major OS has solutions to this problem. It's more up to application makers to use the tools correctly.

Re: Most UI applications are broken real-time applications

#104

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…

> 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. The actual motion-to-photon delay (measurable with a high-speed camera) in a well optimized competitive FPS is somewhere around 20ish ms or less these days, so it's on par with it in regards to…

There’s a big difference in latency on a 10k$ machine and my “non-budget but on a budget” 3k$ machine. You can’t realistically expect people to pay pro-gaming prices.

Re: Most UI applications are broken real-time applications

#105
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…

> 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.

There are great examples even outside of the gaming world. I wish there were videos around on how fluid were Scala Multimedia presentations on a bare Amiga 500 in the 90s. An 8MHz clocked machine (7.16 MHz here in the EU for PAL synchronization) that in that field would outperform gear costing at least an order of magnitude more. It was hugely successful back in the day in many local TV stations.

Re: Most UI applications are broken real-time applications

#106
post #96

I miss running Photon on QNX, which, being a hard real-time OS, did have upper bounds on timing for many operations. Photon was a GUI for near real time interfaces for hard real time programs. It was far smoother than what we see today. * No paging. Entire program in memory at all times. Although it was possible to put a paging library inside an application and let it manage its own paging, which was done for gcc. *…

> Everything is always on. Power consumption is constant. No CPU slowdowns, no sleep modes, no battery saving. This is just fine when you're running a rolling mill, and 99+% of the power is driving the heavy equipment. Not so good when you're running a credit card terminal. Battery powered devices cannot run well in this mode.

Is there no possibility for compromise here?

A credit card terminal sits idle 99%+ of the time, does little actual work, and whatever work it actually does, it's in a reaction to an input event (such as user pressing a button, or a command being sent from cash register). CPU power states are, to my understanding, something you can switch between many times in a fraction of a second. Outside of talking to the network, duration of which is by nature unpredictable, everything else falls into two modes - "slow mode" for listening to events (and perhaps doing whatever is needed to keep the network connection alive), and "fast mode" for processing those events. Sounds to me you could put a real-time guarantee on everything except the networking parts, and keep the CPU slow/sleeping for most of the time.

Re: Most UI applications are broken real-time applications

#107
post #96

I miss running Photon on QNX, which, being a hard real-time OS, did have upper bounds on timing for many operations. Photon was a GUI for near real time interfaces for hard real time programs. It was far smoother than what we see today. * No paging. Entire program in memory at all times. Although it was possible to put a paging library inside an application and let it manage its own paging, which was done for gcc. *…

> Everything is always on. Power consumption is constant.

That was the case in ye olden days of single-core CPUs, but is it still true today?

I can easily imagine a computer that has one always-on core for kernel chores and hardware management, and a dozen dormant cores that wake up when userland tasks need those cycles, all running in hard real time. Or even better, a mix of real-time for UI & audio on some cores + non-time-bound jobs on others.

Re: Most UI applications are broken real-time applications

#108
Windows Phone 7 fixed this in a way - it had a UI thread that could not be used for anything but UI updates. Your event handlers would be executed on a different thread. As long as you showed the loader, the rest of the app would work perfectly smooth.

It's been few years since then so I am light on details.

---

Also, as much as devs hate javascript, it mostly solves this by having 1 thread and offloading all system calls to another via callbacks? So the solution to your issue is: Use electron. (Just kidding, but there is some truth in it)

Re: Most UI applications are broken real-time applications

#110
post #56

Earlier quoted context omitted.

Can you be more specific about what was “solved” in the 90s? The platforms upon which apps are run now and the technologies as well as the expected capabilities of those apps have drastically changed. Not all UI development has changed just for being shiny. I see little reason why building a UI today cannot be a superset of what was solved in the 90s so I’m curious to know what that solved subset looks like to you

Just start with the fact that all desktop programs had a menu bar where you could find every feature - and at least on Windows - also a shortcut for that feature. This was broken with Ribbon and the hamburger menus that every application seems to have switched to for no other reason it seems than to copy Chrome. To be fair Ribbon is somewhat useable again, but the in the first version I have no idea how people were s…

You list a bunch of unrelated things that has absolutely nothing to do with the topic: UIs back in the day had less latency, by not caring about accessibility, internationalization, etc - but I’m quite sure they were way worse off in terms of properly handling blocking operations: you surely know the Solitaire effect
Post reply on HN