Live data from Hacker News

Most UI applications are broken real-time applications

thelig.ht

81–90 of 151 posts

Re: Most UI applications are broken real-time applications

#81
post #58

Earlier quoted context omitted.

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

They care a lot if they get bad reviews online. That translates directly into sales. An insane amount of money and effort that goes into most AAA games. It seems like a stretch to accuse the industry of not caring about the quality of the games they make.

Well, yes, I explained myself horribly.

What I meant is that most people are way more sensitive to graphics than anything else. A lot of people will never play a game that is ugly but don't seem to mind laggy inputs.

There are a lot of games that, even without "real" input lag, have tons of animation dampening/inertia to the point that it makes them IMHO unresponsive, just to improve the "cinematic feel" and avoid characters instantly changing direction.

If you prefer responsiveness to having the player character spin be perfectly smooth, well, sucks to be you, because prettier games sell better.

Obviously this doesn't apply to fighting games or competitive shooters or anything like that where responsiveness is the point of the game.

Re: Most UI applications are broken real-time applications

#82
post #47

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.

> Android (and I believe iOS does too) enforce that. This is absolutely not true. Android simply detects that there has been no progress on the UI thread "for a few seconds" before force-closing the app [1]. By this time, the interaction has been janky/frozen for WAY too long. If you have seen bad iOS scrolling and lock-ups, you know this as well. I have worked on mobile software for these apps that have billions of…

Interesting, probably my IDE (Android Studio) only warned me about that, but I took the warning for an error and never even tried to do the wrong way.

Re: Most UI applications are broken real-time applications

#83
post #58

Earlier quoted context omitted.

They care a lot if they get bad reviews online. That translates directly into sales. An insane amount of money and effort that goes into most AAA games. It seems like a stretch to accuse the industry of not caring about the quality of the games they make.

Well, yes, I explained myself horribly. What I meant is that most people are way more sensitive to graphics than anything else. A lot of people will never play a game that is ugly but don't seem to mind laggy inputs. There are a lot of games that, even without "real" input lag, have tons of animation dampening/inertia to the point that it makes them IMHO unresponsive, just to improve the "cinematic feel" and avoid ch…

Yeah, there's a lot of games where I don't care about lag. Donut County is a little drifty? Great, that fits the aesthetic. But some games really need to be tight.

Re: Most UI applications are broken real-time applications

#84
post #58

Earlier quoted context omitted.

They care a lot if they get bad reviews online. That translates directly into sales. An insane amount of money and effort that goes into most AAA games. It seems like a stretch to accuse the industry of not caring about the quality of the games they make.

Well, yes, I explained myself horribly. What I meant is that most people are way more sensitive to graphics than anything else. A lot of people will never play a game that is ugly but don't seem to mind laggy inputs. There are a lot of games that, even without "real" input lag, have tons of animation dampening/inertia to the point that it makes them IMHO unresponsive, just to improve the "cinematic feel" and avoid ch…

> What I meant is that most people are way more sensitive to graphics than anything else. A lot of people will never play a game that is ugly but don't seem to mind laggy inputs.

Maybe. I wouldn’t be surprised most people are much more sensitive to input latency than we think. But when there’s input latency, they have no idea that that’s the problem so instead they attribute the slushy feel of the game on something else. Or just don’t enjoy the game as much without knowing why. Game developers talk a lot about “game feel” and this is the kind of thing they’re talking about.

Re: Most UI applications are broken real-time applications

#85
post #47

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.

> Android (and I believe iOS does too) enforce that. This is absolutely not true. Android simply detects that there has been no progress on the UI thread "for a few seconds" before force-closing the app [1]. By this time, the interaction has been janky/frozen for WAY too long. If you have seen bad iOS scrolling and lock-ups, you know this as well. I have worked on mobile software for these apps that have billions of…

Attempting a network operation on the Android UI thread will throw the android.os.NetworkOnMainThreadException exception, and has done since API 11 (Honeycomb) in 2011.

https://developer.android.com/reference/android/os/NetworkOn...

Re: Most UI applications are broken real-time applications

#86
post #75

Earlier quoted context omitted.

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

You're right, Sysinternals Process Monitor will show lots of stuff going on for your example.

Re: Most UI applications are broken real-time applications

#87

Im happy even with JetBrains products. They display "working" popup on blocking operations, and do a lot of stuff in the background, which is not blocking my work.

I've finally learned to love VS Code, but the new UI of Clion is pretty damn decent

Re: Most UI applications are broken real-time applications

#88
post #29

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.

My biggest issue with i3 (which I generally love and have used for 5+ years) is that if I switch to a workspace, launch an application with dmenu, and switch to a different workspace before the application loads, the application will load on the current workspace instead of the workspace I originally launched the application from. Anyone have a solution?

Re: Most UI applications are broken real-time applications

#89
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.

My biggest issue with i3 (which I generally love and have used for 5+ years) is that if I switch to a workspace, launch an application with dmenu, and switch to a different workspace before the application loads, the application will load on the current workspace instead of the workspace I originally launched the application from. Anyone have a solution?

Same with Sway.

Re: Most UI applications are broken real-time applications

#90
> This doesn’t seem like a common problem but whole system “out of memory” conditions are not that uncommon. When the system is in this state, it starts rapidly paging memory onto the hard disk. UI applications will be affected and this will cause your system to hang without warning and with no way to intervene since keypresses cannot be processed. From a user standpoint, this is worse than a kernel panic. This type of failure has happened to me multiple times on Linux so I know it’s a problem there. Perhaps Windows and macOS engineers have already considered this issue but I doubt it.

In my experience this is only a problem on Linux. Windows and mac will simply inform you that the system is running out of memory and then you can kill things to set it right. No hung system.

Post reply on HN