2 ms·

>> it would be pretty hard to hit 16.6ms Hard disagree. Sorry, but rant inc ... If we can't hit 60fps with a chat app, one of the simplest applications imagi

>> it would be pretty hard to hit 16.6ms Hard disagree. Sorry, but rant inc ... If we can't hit 60fps with a chat app, one of the simplest applications imaginable by man, what the hell can we hit 60 with? It's drawing a couple thousand triangles (maybe) with a couple hundred textures (I guess). Game engines fart a couple thousand triangles when they're done drawing 50x+ that. Oh, and they do about a gazillion other operations .. at 60fps+ The slow part of switching between conversations is fetching the data which, on a fiber connection in a city, is < 5ms round trip. Hell, I live in the boonies in Canada and my round trip to Seattle is only like 20ms. You could also cache the first 20 messages to every conversation (disk space is cheap) to avoid the network. As for the notion that "you need to care about such low-level things ...", yes, you do. To write fast software you just deal with it and move on.

seba_dos1 4y ago
Being able to hit 60fps is just a single prerequisite for low latency, but it's far from enough - and most importantly, it's not what I was talking about at all. The application may be able to render itself consistently even in 2ms just fine, but effect of your action won't appear on the screen until much later unless you make your whole stack (including the OS) surprisingly complex (which is worth doing in case of competitive video games running in fullscreen, not for applications). Seems like you're simply not aware of complexities of the input to display path. Please make a simple windowed OpenGL application displaying a single triangle in a fraction of millisecond that changes color when you press a key and measure its latency, you may be surprised ;) Did you know that merely enabling FPS limiter on Steam Deck imposes additional latency just because there's currently no way to do it better when using XWayland? That's what "low-level" meant in my comment.
- jesse__ 4y ago
  Okay, I see what you're getting at now, and yes, there are a few frames of latency between the time the app is done drawing and the time pixels are in front of your eyeballs, but that is _completely_ missing my point, and the point of the tweet. If we're splitting hairs about how we define how long an application takes to update, we've already won. In reality, we're talking about an app that should take ~0.01s to perform an operation (update a rectangular region with text), that's taking 1.0s instead. And that's THE OPTIMIZED VERSION. In the real world, we've already lost, which is what Casey was pointing out in his tweet.
  - seba_dos1 4y ago
    The only measure the user cares about when it comes to snappiness while switching between conversations is input-to-display latency, and the whole point of my comment was to be realistic about it. A chat app won't hit 16.6ms latency, but it doesn't have to. 100-200ms is realistic and perfectly fine, and if you don't manage to hit it, something is seriously wrong with your application. And yes, of course, something is seriously wrong with a lot of applications these days, otherwise we wouldn't be having this conversation at all.

seba_dos1 4y ago

Being able to hit 60fps is just a single prerequisite for low latency, but it's far from enough - and most importantly, it's not what I was talking about at all. The application may be able to render itself consistently even in 2ms just fine, but effect of your action won't appear on the screen until much later unless you make your whole stack (including the OS) surprisingly complex (which is worth doing in case of competitive video games running in fullscreen, not for applications). Seems like you're simply not aware of complexities of the input to display path. Please make a simple windowed OpenGL application displaying a single triangle in a fraction of millisecond that changes color when you press a key and measure its latency, you may be surprised ;) Did you know that merely enabling FPS limiter on Steam Deck imposes additional latency just because there's currently no way to do it better when using XWayland? That's what "low-level" meant in my comment.

jesse__ 4y ago
Okay, I see what you're getting at now, and yes, there are a few frames of latency between the time the app is done drawing and the time pixels are in front of your eyeballs, but that is _completely_ missing my point, and the point of the tweet. If we're splitting hairs about how we define how long an application takes to update, we've already won. In reality, we're talking about an app that should take ~0.01s to perform an operation (update a rectangular region with text), that's taking 1.0s instead. And that's THE OPTIMIZED VERSION. In the real world, we've already lost, which is what Casey was pointing out in his tweet.
- seba_dos1 4y ago
  The only measure the user cares about when it comes to snappiness while switching between conversations is input-to-display latency, and the whole point of my comment was to be realistic about it. A chat app won't hit 16.6ms latency, but it doesn't have to. 100-200ms is realistic and perfectly fine, and if you don't manage to hit it, something is seriously wrong with your application. And yes, of course, something is seriously wrong with a lot of applications these days, otherwise we wouldn't be having this conversation at all.