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

141–150 of 151 posts

Re: Most UI applications are broken real-time applications

#141

Post by Animats »

antipurist wrote: post #107
Animats wrote: 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 +…

There's the problem of what does the power management, shut down, and start up of dormant parts of the CPU. If that steals cycles from the OS, it can interfere with real time processing.

There's no reason that CPUs couldn't be designed to avoid such interference, but don't expect to find that on x86. Not sure about ARM.

Re: Most UI applications are broken real-time applications

#142

Post by brundolf »

TeMPOraL wrote: post #140
brundolf wrote: post #138

Earlier quoted context omitted.

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.

It blocks the logic flow of the current function, but in a way that can be resumed later

If it helps you think about it, any await statement can be converted straightforwardly to an old-fashioned promise resolution with a callback:

  async function foo1() {
    doStuff()

    const res = await doIO()

    return 'Result: ' + res
  }

  function foo2() {
    doStuff()

    return doIO().then(res => {
      return 'Result: ' + res
    })
  }

Re: Most UI applications are broken real-time applications

#143

Post by brundolf »

taeric wrote: post #139
brundolf wrote: post #138

Earlier quoted context omitted.

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…

Every click will immediately fire a request, and they will come back in whatever order they come back in based on the server's timing (and network latency, and whatever else)

Done the straightforward way, you will end up displaying whichever one took the longest to return. I've run into this class of bug before, and since then I make sure to design my primitives to guard against it (always assign the latest-requested instead of latest-received result into state)

Re: Most UI applications are broken real-time applications

#144

Post by RecycledEle »

ReactiveJelly wrote: post #100
RecycledEle wrote: post #78

Yes. UI should be run in a separate processor in real time. I am tired of clicking to see the screen change after I click and the click registers on the new screen, not what I clicked on.

Total overkill. If the screen loading is slower than a frame because of... - I/O like file access or networks, you can punt to an async framework like Rust's Tokio - CPU number crunching like cracking a password, you can punt to a worker thread (like Tokio's `spawn_blocking`) The kernel scheduler is smart enough to give time slices to the UI thread even if the password-cracking thread is trying to eat as much CPU as…

I disagree that a dedicated I/O processor is overkill. We spend a lot of transistors and code to solve problems that occur very rarely. Obscure race conditions come to mind. Putting the UI in real time would save me hassle every day, so it's worth the effort.

Adding USB ports to a video card would achieve 99% of the hardware requirements. The other 1% is made up of things I have overlooked.

The software would be more complicated, but it would not require rewriting applications. It would mostly be recoding OSes.

Also, the security benefits of linking output the screen to input from the keyboard and mouse in real time would be substantial.

Re: Most UI applications are broken real-time applications

#145

Post by taeric »

brundolf wrote: post #143
taeric wrote: post #139

Earlier quoted context omitted.

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…

Every click will immediately fire a request, and they will come back in whatever order they come back in based on the server's timing (and network latency, and whatever else) Done the straightforward way, you will end up displaying whichever one took the longest to return. I've run into this class of bug before, and since then I make sure to design my primitives to guard against it (always assign the latest-requested…

Awesome, thanks for confirming my thoughts there. Was hoping to prototype a test soon.

Re: Most UI applications are broken real-time applications

#146

Post by TeMPOraL »

brundolf wrote: post #142
TeMPOraL wrote: post #140

Earlier quoted context omitted.

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.

It blocks the logic flow of the current function, but in a way that can be resumed later If it helps you think about it, any await statement can be converted straightforwardly to an old-fashioned promise resolution with a callback: async function foo1() { doStuff() const res = await doIO() return 'Result: ' + res } function foo2() { doStuff() return doIO().then(res => { return 'Result: ' + res }) }

That's what I thought. But then, unless foo2() is an async function, the entire thread that's running foo2() will be blocked, will it not?

Re: Most UI applications are broken real-time applications

#147

Post by brundolf »

TeMPOraL wrote: post #146
brundolf wrote: post #142

Earlier quoted context omitted.

It blocks the logic flow of the current function, but in a way that can be resumed later If it helps you think about it, any await statement can be converted straightforwardly to an old-fashioned promise resolution with a callback: async function foo1() { doStuff() const res = await doIO() return 'Result: ' + res } function foo2() { doStuff() return doIO().then(res => { return 'Result: ' + res }) }

That's what I thought. But then, unless foo2() is an async function, the entire thread that's running foo2() will be blocked, will it not?

Nope. It returns a promise, which other logic can then hang a callback off of. But the promise is returned immediately (if just resolves and calls the callback later, like any event listener would)

Re: Most UI applications are broken real-time applications

#148

Post by smokel »

hypertele-Xii wrote: post #124
proc0 wrote: post #61

Earlier quoted context omitted.

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…

Using pixel coordinates for 2D space is like sizing web elements in pixels - it's just plain wrong and will look vanishingly small on future higher-resolution monitors.

It's just plain wrong from today's perspective. Back when pixel sizes were predictable, one could exploit this at all levels.

Pixel artists would (and still continue to) consider every individual pixel, performing anti-aliasing by hand. Animations would be timed in relative to the (fixed) framerate, leading to optimal smoothness.

Reaching this level of fluidity is only recently possible again, at the cost of vastly higher hardware requirements. Most people haven't even experienced this, because of the suboptimal period we have been in for some time now.

You win some, you lose some.

Re: Most UI applications are broken real-time applications

#149

Post by hypertele-Xii »

zogrodea wrote: post #127
hypertele-Xii wrote: post #124

Earlier quoted context omitted.

Using pixel coordinates for 2D space is like sizing web elements in pixels - it's just plain wrong and will look vanishingly small on future higher-resolution monitors.

Wasn't it common practice on older systems like, say, the SNES Sega Genesis? A design responsive to multiple resolutions wasn't really a thing back then as far as I know.

Imagine the richness of retro gaming today if they had had the foresight to design for resolution independence. Now only a vanishingly tiny subset of the best of the best games have the financial incentive or dedicated modding community to release in high definition.

Re: Most UI applications are broken real-time applications

#150

Post by proc0 »

hypertele-Xii wrote: post #124
proc0 wrote: post #61

Earlier quoted context omitted.

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…

Using pixel coordinates for 2D space is like sizing web elements in pixels - it's just plain wrong and will look vanishingly small on future higher-resolution monitors.

I was speaking a little more abstractly. For 2D, even if you use an intermediate coordinate system, the transformation between the two can be mapped 1:1 with the controller (in theory, not that you need to), because controllers are 2D in design (specifically the directional arrows and joysticks, which have 2D coordinates). I think allows for more natural responsiveness. If controllers had 3D joysticks, or eventually when VR gets better at hand motion, then 3D responsiveness will improve.
Post reply on HN