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

41–50 of 151 posts

Re: Most UI applications are broken real-time applications

#41

Post by alex7734 »

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…

> But if the input is laggy, I'll feel that the entire time I'm playing.

You've already bought the game at this point so most devs don't care.

Re: Most UI applications are broken real-time applications

#42

Post by pests »

dgan wrote: post #32
_y5hn wrote: post #29

Earlier quoted context omitted.

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.

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

Re: Most UI applications are broken real-time applications

#43

Post by _y5hn »

dagenleg wrote: post #33
_y5hn wrote: post #29

Earlier quoted context omitted.

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.

Sounds great, how did you do that? What's the config option?

I believe it may depend on i3 version, but you can make it work with the no_focus command, and ie. any window title, all, etc.: https://askubuntu.com/questions/1379653/is-it-possible-to-st...

Re: Most UI applications are broken real-time applications

#44

Post by anonymoushn »

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.

For a game like Street Fighter, you can present to someone the time at which the first frame begins and all of the input events within the game and they can calculate the unique game outcome that results. It's a bit embarrassing that we cannot have the same property in applications that we interact with using our keyboards all day, and we must constantly look at them to see if they are behaving as if we have sent the inputs we have sent.

Re: Most UI applications are broken real-time applications

#45

Post by _y5hn »

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

Yep. Non-blocking threads was a thing in the 90's also. BeOS probably the poster-child of that.

Re: Most UI applications are broken real-time applications

#46

Post by dzaima »

anonymoushn wrote: post #30
dzaima wrote: post #28

The reality is that optimizing for the common scenario just gives such significant benefits that the worst-case scenario becomes practically infeasible to even consider. And it's not just OSes that don't particularly care about real-time - modern processors don't either. e.g., in the common scenarios it's possible to load maybe eight 8-byte values per nanosecond (maybe eight 32-byte values if you're doing SIMD), but…

I feel like this comment is from an alternate reality where the Windows lock screen doesn't just drop all your inputs for a random period of at least a few seconds when you try to enter your password.

It is very much true that there's a very large amount of things that could be improved on the status quo with rather minimal amounts of effort, that could resolve a vast majority of the brokenness of responsiveness of UIs. But decreasing dropped frames/inputs by 10x or 100x is still just simply not gonna make it "real-time".

I remember the windows lock screen being particularly annoying (an animation had to finish..?) but on Linux Mint I've always been able to start typing away immediately, so much so that I start blindly typing in the password before my monitor has finished turning on. Properly queueing events (keyboard ones at least) should be pretty simple to do properly, but of course many things still get it wrong.

Re: Most UI applications are broken real-time applications

#47

Post by deepsun »

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.

Re: Most UI applications are broken real-time applications

#48

Post by _greim_ »

Web browsers should add a DOM method called `addEventStream()` to supplement `addEventListener()`. It would still accept an event type—e.g. `button.addEventStream('click')`—but would not accept a handler function. It would just return an async iterator of event objects. Backpressure on the iterator would place the element into a `:waiting` state similar to `:disabled` in which the element would become non-interactive. All UI event handling becomes a data processing pipeline.

Re: Most UI applications are broken real-time applications

#49

Post by _y5hn »

OliverGilan wrote: post #35
_y5hn wrote: post #29

Earlier quoted context omitted.

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.

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

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.

Re: Most UI applications are broken real-time applications

#50

Post by adroitboss »

So is the moral of the story is to build an entire OS like erlang's actor model? Doesn't that work by using lightweight threads and messaging passing between them. The supervisor gives each thread a certain amount of time to run and then puts the current thread on the back burner while the next thread runs for it's allotted time. I remember hearing it in an erlang talk by Joe Armstrong on Youtube. I can't remember which one though.
Post reply on HN