3 ms·

One thing that id did to hit their target framerate of 60fps on (IIRC) Quake 3 is have a policy that boiled down to: "We always run at 60 fps, because if we fi

One thing that id did to hit their target framerate of 60fps on (IIRC) Quake 3 is have a policy that boiled down to: "We always run at 60 fps, because if we finish the game, then try to optimize our way to 60, we'll never hit it." >> This suggests that there is probably a handful of things they are doing that are low-hanging fruit ... The Quake annecdote suggests the opposite. If I had to guess (from personal experience with web development), it's probably a million-billion little things that, when added up, make your whole project a slow, gelatinous pile. That's not to say there's not also low-hanging fruit that might make switching between conversations take less than a second, but .. it should take .. like .. a short amount of time, like 16.6ms, including the network trip.

seba_dos1 4y ago
Let's be realistic, it would be pretty hard to hit 16.6ms. Not impossible, but very complex with little benefit (at this point you need to care about such low-level things as the way you schedule frames to be displayed by system compositor, for example - and even how the compositor itself is doing its work too!). Something like 200ms, however, should be perfectly achievable with little effort and just as snappy in practice for this kind of app :) (note that a game running at 60 FPS does not mean that you get 16.6ms mouse-to-screen latency at all)
- amoss 4y ago
  Why? In 16.6ms a modern processor will execute about 128 million instructions. We need to locate about a screenful of text and/or cat pictures. We need to perform layout and then render it. The amount of work being done is not very much, or very difficult. The resources available are luxurious. What part of the problem is it that makes it an unrealistic target?
  - seba_dos1 4y ago
    Because most screens are running at 16.6ms refresh rate, composition is vsynced and windows are double-buffered at multiple stages in the whole display pipeline to avoid tearing and other kinds of artifacts. You're naturally going to have 2-3 frames of latency unless you try really hard to avoid it with advanced frame scheduling that won't be worth employing (or maybe even feasible to employ) for an office application. You usually optimize application rendering for smoothness (no frame drops, no artifacts, consistent 60 FPS) rather than latency, and improving one usually hurts the other. And that's ignoring the input path, which brings its own latencies too.
    - amoss 4y ago
      Ah, ok so you are considering the latency rather than the throughput. I was thinking that being able to perform the update within 16.6ms should not be too hard - there is a sibling comment about SSD latency but the working set should fit in RAM. Sure, so there will be latency, maybe 4-5 frames with input lag. But this is normally bearable in a game so I'm guessing that it would work fine for an office app. It would be difficult to remove, but 80ms response time from an application that can always hit its 16.6ms deadline should be workable.
      - seba_dos1 4y ago
        We're talking about switching between conversations, latency is all that matters :)
        ehaliewicz2 4y ago
        This seems like needless pedantry. The computer should be able to easily do it in 16ms or less. Add on the 16ms or whatever of extra latency for the mouse and display, and it's fine.
        deleted 4y ago
        [deleted]
        deleted 4y ago
        [deleted]
  - mike_hearn 4y ago
    Disk IO. Even with SSDs it's not that fast.
- jesse__ 4y ago
  >> 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.
skavi 4y ago
I’ve heard Safari doesn’t allow performance regressions. And they currently have the fastest browser.
- illiarian 4y ago
  From the horse's mouth: https://twitter.com/rniwa_dev/status/1578097561222537216 https://twitter.com/rniwa_dev/status/1578097561222537216 (a mini thread, only quoting top tweet) "It's a bit of understatement to say @WebKit project cares about performance or efficiency of the software. We're quite obsessed with it, and we throw a lot of engineering resources at it, not to regress, and to improve upon."

seba_dos1 4y ago

Let's be realistic, it would be pretty hard to hit 16.6ms. Not impossible, but very complex with little benefit (at this point you need to care about such low-level things as the way you schedule frames to be displayed by system compositor, for example - and even how the compositor itself is doing its work too!). Something like 200ms, however, should be perfectly achievable with little effort and just as snappy in practice for this kind of app :) (note that a game running at 60 FPS does not mean that you get 16.6ms mouse-to-screen latency at all)

amoss 4y ago
Why? In 16.6ms a modern processor will execute about 128 million instructions. We need to locate about a screenful of text and/or cat pictures. We need to perform layout and then render it. The amount of work being done is not very much, or very difficult. The resources available are luxurious. What part of the problem is it that makes it an unrealistic target?
- seba_dos1 4y ago
  Because most screens are running at 16.6ms refresh rate, composition is vsynced and windows are double-buffered at multiple stages in the whole display pipeline to avoid tearing and other kinds of artifacts. You're naturally going to have 2-3 frames of latency unless you try really hard to avoid it with advanced frame scheduling that won't be worth employing (or maybe even feasible to employ) for an office application. You usually optimize application rendering for smoothness (no frame drops, no artifacts, consistent 60 FPS) rather than latency, and improving one usually hurts the other. And that's ignoring the input path, which brings its own latencies too.
  - amoss 4y ago
    Ah, ok so you are considering the latency rather than the throughput. I was thinking that being able to perform the update within 16.6ms should not be too hard - there is a sibling comment about SSD latency but the working set should fit in RAM. Sure, so there will be latency, maybe 4-5 frames with input lag. But this is normally bearable in a game so I'm guessing that it would work fine for an office app. It would be difficult to remove, but 80ms response time from an application that can always hit its 16.6ms deadline should be workable.
    - seba_dos1 4y ago
      We're talking about switching between conversations, latency is all that matters :)
      - ehaliewicz2 4y ago
        This seems like needless pedantry. The computer should be able to easily do it in 16ms or less. Add on the 16ms or whatever of extra latency for the mouse and display, and it's fine.
        deleted 4y ago
        [deleted]
        deleted 4y ago
        [deleted]
- mike_hearn 4y ago
  Disk IO. Even with SSDs it's not that fast.
jesse__ 4y ago
>> 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.

skavi 4y ago

I’ve heard Safari doesn’t allow performance regressions. And they currently have the fastest browser.

illiarian 4y ago
From the horse's mouth: https://twitter.com/rniwa_dev/status/1578097561222537216 https://twitter.com/rniwa_dev/status/1578097561222537216 (a mini thread, only quoting top tweet) "It's a bit of understatement to say @WebKit project cares about performance or efficiency of the software. We're quite obsessed with it, and we throw a lot of engineering resources at it, not to regress, and to improve upon."