4 ms·

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 perf

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

by amoss 4y ago

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.