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

121–130 of 151 posts

Re: Most UI applications are broken real-time applications

#121

Post by kaba0 »

TeMPOraL wrote: post #118
kaba0 wrote: post #110

Earlier quoted context omitted.

You list a bunch of unrelated things that has absolutely nothing to do with the topic: UIs back in the day had less latency, by not caring about accessibility, internationalization, etc - but I’m quite sure they were way worse off in terms of properly handling blocking operations: you surely know the Solitaire effect

At the very least, you knew that when the UI locks up, it's actually doing something. These days, previously-blocking operations may be run async, but the result is that, every now and then, the UI will miss the signal that the async job completed (or failed). An UI that regularly desyncs from reality is a relatively new problem.

> At the very least

I don’t care if the food is bad because it is too salty, or because it is overcooked, I still won’t eat it.

Re: Most UI applications are broken real-time applications

#122

Post by TeMPOraL »

valbaca wrote: post #8
m463 wrote: post #3

I believe I agree. The iPhone UI must have either a realtime UI (or something pretty snappy). It responds to finger inputs in a bounded way.

Dispatch queue. Android has the equivalent thing.

> Dispatch queue. Android has the equivalent thing.

Must be disabled on Samsung flagships, as these are the ones I have experience with, and I wouldn't say touch response is bounded on them, not for any useful definition of "response" and "bounded".

The last mobile device I used that had sane input response was a Sony Ericsson K800i feature phone. Input processing on it was fast, and most importantly, consistent. That means predictable - I could do most stuff on that phone while keeping it in my pocket, because I muscle-memorized the input sequences and how long every action took. Such a thing is impossible on smartphones.

Re: Most UI applications are broken real-time applications

#123

Post by TeMPOraL »

kaba0 wrote: post #121
TeMPOraL wrote: post #118

Earlier quoted context omitted.

At the very least, you knew that when the UI locks up, it's actually doing something. These days, previously-blocking operations may be run async, but the result is that, every now and then, the UI will miss the signal that the async job completed (or failed). An UI that regularly desyncs from reality is a relatively new problem.

> At the very least I don’t care if the food is bad because it is too salty, or because it is overcooked, I still won’t eat it.

You'll reconsider when your only alternative is food that's cooked perfectly, but also bacteriologically contaminated.

Re: Most UI applications are broken real-time applications

#124

Post by hypertele-Xii »

proc0 wrote: post #61
TacticalCoder wrote: post #5

Earlier quoted context omitted.

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

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.

Re: Most UI applications are broken real-time applications

#125

Post by scott_w »

masfuerte wrote: post #60
scott_w wrote: post #24

Earlier quoted context omitted.

If I recall correctly, the PS4 controller has a disgusting amount of input delay. I noticed this most strongly on the FFX Remaster where you need to hit timer events before the arrow enters the shaded box. It doubly screws you in the chocobo racing section because the controls assume no delay, meaning you can’t respond to hazards in time and constantly overcorrect movement.

Some multiplayer network games memoise the game state. When an input event arrives from a remote player it is applied to the game state that existed at the time of the event. Then the state is fast-forwarded to the present time and the game continues. Ideally you shouldn't notice this happening. The obvious fix for laggy input is to apply the same processing to local input, but I've not heard of anyone doing this. (I…

I think native PS4 games did something like this to work around it. Final Fantasy X was a PS2 game ported to PS4, so I doubt they re-wrote their controller code to that extent, especially given how noticeable it was.

Re: Most UI applications are broken real-time applications

#126

Post by jonathanlydall »

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.

I’m a Windows fan, but this bugs me so much, prior to Windows 8 I could go Ctrl Alt Del and instantly start typing my password, now I have to wait a couple of seconds before entering being able to enter my PIN.

Re: Most UI applications are broken real-time applications

#127

Post by zogrodea »

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.

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.

Re: Most UI applications are broken real-time applications

#128

Post by dTP90pN »

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.

To be fair, SDDM has the same issue, at least on multi monitor setups.

Re: Most UI applications are broken real-time applications

#129

Post by taeric »

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.

My favorite is when someone builds a ton of filtering capability locally that loads all of the data and then filters it down. Was a common mistake many editors (such as emacs) used to make, so not at all blaming incompetence. But is absolutely a trap.

Re: Most UI applications are broken real-time applications

#130

Post by kaba0 »

TeMPOraL wrote: post #119
orbital-decay wrote: post #27

Earlier quoted context omitted.

> People don't understand that their 144 Hz monitor running a 3D game still doesn't convey that smoothness that my vintage arcade cab does when running an old 2D game with pixel-perfect scrolling while never skipping a frame. 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 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?
Post reply on HN