Most UI applications are broken real-time applications • Hacker News Board

Re: Most UI applications are broken real-time applications

#61

Post by proc0 » Thu, Sep 21, 2023, 8:40 PM UTC

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…

I think the difference is that 3D is inherently continuous (because it is simulating a 3d space) and requires another layer of abstraction on top of the controllers to work intuitively. 2D on the other hand is pixel based which is usually discrete (the world units are uniform in pixels), and also the character movement is 1:1 mapping on the controller. These two factors make 2D feel more responsive, and I'm guessing that once VR gets better it will close the abstraction gap and make the controller mapping (body/hand movement) 1:1.

Re: Most UI applications are broken real-time applications

#62

Post by _y5hn » Thu, Sep 21, 2023, 8:41 PM UTC

redserk wrote: post #53

_y5hn wrote: post #49

Earlier quoted context omitted.

There were all kinds of standards, guidelines that made people recognize what the program is doing and how to operate it. Nowadays, UIs are mostly defective, trying its best to hinder effective usage and hide/strip functionality. There are of course progress too, but something was lost that make applications today much less intuitive and hard/tough to use.

I don't understand what specifically is of concern here. Do you have exact examples? Some platforms publish a list of recommended guidelines which are effectively a standard. For example here's one from Apple about when and how to use charts in an application: https://developer.apple.com/design/human-interface-guideline...

Some of it may be found in older HIG sources sure: https://en.m.wikipedia.org/wiki/Human_interface_guidelines

Also they were called GUI standards or UI at the time.

The modern equivalents called UX isn't reflecting the same conglomeration of standards and conventions though. So not talking about the newer stuff.

I'm no expert on it, and it required specialized expertise. It's been abandoned for mobile interfaces and the modern UX stuff, which often optimizes for design over functionality.

If you've never used old software, it's hard to explain. But old Apple or Microsoft GUI standards would cover the basics, but you'd also need to study the applications and how they presented their GUI.

Re: Most UI applications are broken real-time applications

#63

Post by johannes1234321 » Thu, Sep 21, 2023, 8:41 PM UTC

redserk wrote: post #53

_y5hn wrote: post #49

Earlier quoted context omitted.

There were all kinds of standards, guidelines that made people recognize what the program is doing and how to operate it. Nowadays, UIs are mostly defective, trying its best to hinder effective usage and hide/strip functionality. There are of course progress too, but something was lost that make applications today much less intuitive and hard/tough to use.

I don't understand what specifically is of concern here. Do you have exact examples? Some platforms publish a list of recommended guidelines which are effectively a standard. For example here's one from Apple about when and how to use charts in an application: https://developer.apple.com/design/human-interface-guideline...

Back in the days™ there were widget libraries as part of the OS, which followed the guidelines by the OS vendor. This gave a foundation for somewhat similar behavior and standardisation of behavior. This gives usability.

Nowadays man's applications are web apps, build without such frameworks, with less UI research and even where frameworks are used they are often built with a somewhat mobile first approach.

Re: Most UI applications are broken real-time applications

#64

Post by yetanotherloss » Thu, Sep 21, 2023, 8:50 PM UTC

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

More like three decades. But you'll need to send the memo to small time players like Microsoft, who continue doing all kinds of stupid blocking IO on every possible user interaction because who even fucking knows.

Re: Most UI applications are broken real-time applications

#65

Post by nitwit005 » Thu, Sep 21, 2023, 8:52 PM UTC

> This is a transparent process that is not under control of the application. Thus, if any given memory access can block on IO from a disk drive, that means the system is fundamentally not real-time, therefore UI applications on such a system are fundamentally broken.

Not really. It means they chose to degrade performance when too much memory is used, rather than crash.

All options available when "out of memory" are bad. They thought that was the least bad option.

Re: Most UI applications are broken real-time applications

#66

Post by [deleted] » Thu, Sep 21, 2023, 8:58 PM UTC

eitland wrote: post #56

OliverGilan wrote: post #35

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…

[deleted]

Re: Most UI applications are broken real-time applications

#67

Post by ComputerGuru » Thu, Sep 21, 2023, 8:58 PM UTC

frostiness wrote: post #52

ComputerGuru wrote: post #40

I agree with the main gist of the article and a lot of the points, but disagree on a few specifics. 1) mlock isn’t meant to be called on all your memory, just something that needs it to operate correctly. The situation the author described where the system comes to a halt as memory contents are paged in and out of memory/disk is (subjectively) worse when the only option is for the OOM killer to begin reaping processe…

> The situation the author described where the system comes to a halt as memory contents are paged in and out of memory/disk is (subjectively) worse when the only option is for the OOM killer to begin reaping processes everywhere. This one's interesting since your outcome often depends on what hardware you have. On systems with slow IO, i.e. a slow HDD, it's possible for swapping to make a system entirely unusable fo…

But in the era when spinning rust startup disks were in use everywhere, no app would autosave. I can’t imagine the carnage if MS Word or Excel were just violently killed at the first sign of memory pressure back in the day.

Re: Most UI applications are broken real-time applications

#68

Post by theamk » Thu, Sep 21, 2023, 8:59 PM UTC

pests wrote: post #42

dgan wrote: post #32

Earlier quoted context omitted.

You are replying out of context: if your file is on a network drive it doesn't matter if you have shiny UI, or text based terminal, you gonna wait for the round trip with your UI being unresponsive

That doesn't follow. Your UI can be responsive while the round trip happens. The application won't literally stop working 100%.

Depending on the application. Take single-window editor (think notepad) for example. If the "load" command is blocking, what can you do?

You cannot allow editing - the existing buffer will be replaced once load completes. You can show the menu, but most options should be disabled. And it will be pretty confusing for user to see existing file remain in read-only mode after "open" command.

The most common solution if you expect loads to be slow is a modal status box which blocks entire UI, but maybe shows progress + cancel button. This definitely helps, but also a lot of extra code, which may not be warranted if usual loads are very fast.

Re: Most UI applications are broken real-time applications

#69

Post by brundolf » Thu, Sep 21, 2023, 9:03 PM UTC

> One of the fundamental problems is that many UI applications on Windows, Linux, and macOS call functions that are not specified to run in a bounded amount of time. Here’s a basic example: many applications don’t think twice about doing file IO in a UI event handler. That results in a tolerable amount of latency most of the time on standard disk drives but what if the file is stored on a network drive? It could take much longer than a second to service the file request. This will result in a temporarily hung application with the user not knowing what is happening. The network drive is operating correctly, the UI application isn’t.

Say what you will about JavaScript, but a great thing it's done for modern software is making async programming default and ergonomic. With most APIs, you couldn't block on IO if you tried. Which means web UIs never do

Re: Most UI applications are broken real-time applications

#70

Post by Groxx » Thu, Sep 21, 2023, 9:09 PM UTC

btilly wrote: post #34

The article fails to distinguish between hard real-time and soft real-time. If you're controlling a bandsaw, you've got a hard real-time application. You can't miss your window for the next instruction. Most user interfaces are soft real-time. Occasionally missing your window is fine. And so it is OK to do things like hash lookups whose average performance is O(1), and whose worst case performance is O(n). Ditto for…

Agreed here. While I wish more frameworks did what Android did, and allow you to literally block file and network access on the main thread (opt-in strict mode that I wish was default enabled)... worrying about paged memory in an active GUI is so, so much further down the hard-real-time branch of things that the effort/reward ratio is literally insane in almost all cases. It may be a fun challenge for some, but it'll absolutely never be a major use case, nor should it be.