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

71–80 of 151 posts

Re: Most UI applications are broken real-time applications

#71

Post by Groxx »

_y5hn wrote: post #62
redserk wrote: post #53

Earlier quoted context omitted.

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…

While I broadly agree with the UX/HIG/design guideline issues that are common in modern software... literally none of them have anything to do with the technicals of how quickly the UI reacts to actions and renders the next state. You can have responsive UI in all of them. And all the modern ones also say "jank is bad, don't do that".

Re: Most UI applications are broken real-time applications

#72

Post by pradn »

josephg wrote: post #21
dllthomas wrote: post #19

Earlier quoted context omitted.

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.

Strangely enough, I had the same experience with diablo 4 until I turned down some of the graphics settings. I'm not sure if it was some DLSS / frame generation thing or what, but the game felt sloppy to me. Especially in comparison to something like diablo 2 which feels razor sharp. I wish modern game developers & graphics pipelines would spend more effort optimizing input latency. I'll stop noticing the graphics 2…

I’m totally with you. It has a generic art style, and with optimized settings, looks like goop. There’s never going to be a game that feels like how it feels teleporting through a whole act in D2. Everything loads instantly. And it keeps doing that even at high cast speeds.

Re: Most UI applications are broken real-time applications

#73

Post by pests »

theamk wrote: post #68
pests wrote: post #42

Earlier quoted context omitted.

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

Well, notepad is a bad example because it has tabs now. If the load command is blocking, show an indicator of that inside the tab. The user can switch to the other tab and have a full editing experience - this buffer obviously will not be replaced.

If you pick another single-window app, my response is: that is a decision they chose to make. They can also choose to go multi-window or tabbed just like notepad did.

Re: Most UI applications are broken real-time applications

#74

Post by tantalor »

cobbal wrote: post #13
cobbal wrote: post #11

Earlier quoted context omitted.

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.

You can have it fast, or correct, or both, or neither.

Here's an extremely fast sorting algorithm that's incorrect:

  function cobbalSort(arr) { return arr; }

Re: Most UI applications are broken real-time applications

#75

Post by pradn »

deepspace wrote: post #17
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 it…

The file picker on Windows should be thought of as more like a process than a function call. It has to 1) read the metadata of the current directory’s files 2) look up which icon to use for each 3) load the icon 3) call apps that may modify the file icon overlay (like “synced” or “not synced” cloud icons for Cloud file systems like Google Drive) 4) read the registry for various settings 5) load which pinned files a user set up - etc etc. All this involves dozens of disk reads, calling into third party code, etc. A lot of this may be cached but who knows.

The alternative to this is to roll a barebones file picker - there might even be one available in the Windows API.

Re: Most UI applications are broken real-time applications

#76

Post by bhdlr »

_y5hn wrote: post #29
seanalltogether wrote: post #20

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

UI was pretty much solved in the 90's including the problem of instant feedback. Then abandoned for shiny stuff. Personally I set up i3 to open most windows asynchronously, so my flow isn't interrupted. It's great, but takes a bit getting used to windows not randomly stealing focus. It's not for everyone though.

> solved in the 90s

Ya, you know, unless you didn't speak English, needed accessibility, had a nonstandard screen size, had a touch screen, etc

Re: Most UI applications are broken real-time applications

#77

Post by favorited »

valbaca wrote: post #9
senkora wrote: post #4

As 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

Some of Apple's biggest perf wins in the last several years involved removing dispatch asynchrony from code paths that really don't need to be asynchronous.

Obviously if you're writing an event-loop web server, then your file IO needs to be non-blocking or you're hosed. On the other hand, if you're reading a small configuration file from disk after your app launches, the most responsive option may well be to just read the bytes on the current thread and continue.

https://web.archive.org/web/20190606075031/https://twitter.c...

https://web.archive.org/web/20211005132519/https://twitter.c...

Re: Most UI applications are broken real-time applications

#79

Post by 4rt »

seanalltogether wrote: post #20

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

Exactly this, doing it right is possible but vastly more complicated and requires tons more UI work.

It's not impossible - tape drives jukeboxes with 5 minute delays aren't a new invention.

Re: Most UI applications are broken real-time applications

#80

Post by taeric »

brundolf wrote: post #69

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

Huh? It used to be very common to find that a web page was stuck processing some script. Still isn't that uncommon, all told.

You are mostly right that you couldn't block on IO, necessarily, but you could still hose up the event thread quite heavily.

Post reply on HN