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

131–140 of 151 posts

Re: Most UI applications are broken real-time applications

#131

Post by TeMPOraL »

kaba0 wrote: post #130
TeMPOraL wrote: post #119

Earlier quoted context omitted.

> 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 the input lag I.e. more than two frames between input and output. That is quite a lot, and AFAIK a large regression.

It’s the exact same amount of time - why would the frame count matter?

1 - 2 frames is a lot of time and latency this big is perceptible in many tasks, fast-paced videogames being just one of them.

Re: Most UI applications are broken real-time applications

#132

Post by kaba0 »

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…

The “funny” thing is that I can still regularly hit the “sweet” spot where Linux completely freezes with 8GB of rams (with zram) on a fast SSD.. I think the paging logic still has some assumptions that are only true for hard drives, and that put the system into a frenzy - only REISUB works at that point.

Re: Most UI applications are broken real-time applications

#133

Post by kaba0 »

TeMPOraL wrote: post #131
kaba0 wrote: post #130

Earlier quoted context omitted.

It’s the exact same amount of time - why would the frame count matter?

1 - 2 frames is a lot of time and latency this big is perceptible in many tasks, fast-paced videogames being just one of them.

It was in reference to high refresh rate screens - 1-2 frames is not much at 144+ Hz.

Re: Most UI applications are broken real-time applications

#134

Post by dllthomas »

dllthomas wrote: post #19
masfuerte wrote: post #12

Earlier quoted context omitted.

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.

FWIW I took this impetus to check my TV settings, and poking around improved things. It's still not the arcade but it's better.

Re: Most UI applications are broken real-time applications

#135

Post by brundolf »

TeMPOraL wrote: post #120
brundolf wrote: post #94

Earlier quoted context omitted.

If you're actually doing busy logic then it'll block the UI thread, but you have to work pretty hard to do that, and IO won't block the UI thread

All you need to is `await` an IO operation on the UI thread.

Not true. The await statement will kick the operation over to the event loop to wait for a response, and the thread itself will keep humming along (pulling other events off the loop, handling animations and scrolling, etc)

Re: Most UI applications are broken real-time applications

#136

Post by whoopsie »

bc_programming wrote: post #92
eitland wrote: post #56

Earlier quoted context omitted.

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…

A related detail, even things like icon design have gone in a strange direction. In the interest of simplicity they've gone from recognizable to rather amorphous blobs. A button for print has gone from a clearly recognizable image of a printer, enough you could probably even guess the model number, to the icon being a rounded square with another rounded square sticking out the middle top. Many of these newer icons ar…

What’s a printer? Does it make cheap iPads?

Re: Most UI applications are broken real-time applications

#137

Post by TeMPOraL »

brundolf wrote: post #135
TeMPOraL wrote: post #120

Earlier quoted context omitted.

All you need to is `await` an IO operation on the UI thread.

Not true. The await statement will kick the operation over to the event loop to wait for a response, and the thread itself will keep humming along (pulling other events off the loop, handling animations and scrolling, etc)

Not on await, no, unless the caller/awaiter is async too?

Re: Most UI applications are broken real-time applications

#138

Post by brundolf »

TeMPOraL wrote: post #137
brundolf wrote: post #135

Earlier quoted context omitted.

Not true. The await statement will kick the operation over to the event loop to wait for a response, and the thread itself will keep humming along (pulling other events off the loop, handling animations and scrolling, etc)

Not on await, no, unless the caller/awaiter is async too?

The function containing the `await` waits, but the thread does not; it switches to doing other things:

- Page scrolling/rendering

- If the user triggers an event, like clicking on a button, that JS event handler is independent from the waiting function and can run while it's waiting

- Same thing if some other `await`ed IO resolves; that function can resume while the other one is still waiting

This is why async/await exists. It allows our code to tell the runtime "let me know when this is ready, otherwise do whatever you want in the meantime". Many languages have a similar feature now, but in JavaScript it's especially fundamental to the language and ecosystem, which means code gets written this way by default, which means JS programs don't have the problem mentioned in the OP by default.

Re: Most UI applications are broken real-time applications

#139

Post by taeric »

brundolf wrote: post #138
TeMPOraL wrote: post #137

Earlier quoted context omitted.

Not on await, no, unless the caller/awaiter is async too?

The function containing the `await` waits, but the thread does not; it switches to doing other things: - Page scrolling/rendering - If the user triggers an event, like clicking on a button, that JS event handler is independent from the waiting function and can run while it's waiting - Same thing if some other `await`ed IO resolves; that function can resume while the other one is still waiting This is why async/await…

I'm curious how this works with event handlers. Suppose you have one on a button that will fetch a number from a server and show it. For fun, assume the server is basically fizzbuzz, but with a 2 second delay for every multiple of 3/5 and a 1 second delay otherwise. If I click the button 4 times quickly (less than a second for all clicks), what happens?

I'm assuming it is on the programmer to do some smart debouncing in the event handler?

Re: Most UI applications are broken real-time applications

#140

Post by TeMPOraL »

brundolf wrote: post #138
TeMPOraL wrote: post #137

Earlier quoted context omitted.

Not on await, no, unless the caller/awaiter is async too?

The function containing the `await` waits, but the thread does not; it switches to doing other things: - Page scrolling/rendering - If the user triggers an event, like clicking on a button, that JS event handler is independent from the waiting function and can run while it's waiting - Same thing if some other `await`ed IO resolves; that function can resume while the other one is still waiting This is why async/await…

Okay, I think I am confused about how this works in JS. I've written my fair share of event-driven code, but managed to avoid working with actual async/await. My understanding was that calling an async function does what you describe, but awaiting it literally blocks the caller thread - because what else could it block? Your description sounds like something I'd expect of a yield instruction.
Post reply on HN