5 ms·

Unfortunately this isn't true anymore when you get to very high resolutions like 8k. Just clearing the framebuffer of an 8k display at 60hz requires ~6GB/s; abo

Unfortunately this isn't true anymore when you get to very high resolutions like 8k. Just clearing the framebuffer of an 8k display at 60hz requires ~6GB/s; about 1/10th of the theoretical memory bandwidth of modern desktop processors. Add in compositing for multiple windows, text rendering and none of that likely being multi-threaded it's pretty clear a CPU has no chance of keeping up.

fxtentacle 4y ago
You are correct, but so is the comment you replied to. The latency that matters for a text editor is how long it takes for a new keypress to show up. And that's usually a 32x32 pixel area or less.
- gizmo 4y ago
  That's not sufficient, though. You want the 0.1% case where you press undo a couple of times and big edit operations get reversed to be smooth. You have to hit your frame target when a lot is happening, the individual key press case is easy. It's just like a video game. A consistent 60fps is much better than an average frame rate of 120fps that drops to 15fps when the shooting starts and things get blown up. You spend all the time optimizing for the worst case where all your caches get invalidated at the same time.
  - fxtentacle 4y ago
    In a video game, you'd just blur the shit out of everything else while you grant yourself a 2nd frame to re-render the rest of the content [1]. Or you do temporal remapping like the Oculus does if you rotate your head too quickly. [1] https://developer.nvidia.com/blog/nvidia-vrss-2-dynamic-foveated-rendering-no-assembly-required/ https://developer.nvidia.com/blog/nvidia-vrss-2-dynamic-fove...
- ben-schaaf 4y ago
  The other latency that matters is how long it takes to draw each frame when scrolling through the code, which is usually most if not all of the framebuffer.
  - fxtentacle 4y ago
    Agree. In that case, you need to cache the result of your CPU rendering in a GPU texture so that you can smoothly scroll it. But you can probably still get away with drawing all UI components on the CPU if you add a little bit of caching.
jcelerier 4y ago
But when you do software rendering you don't need to redraw the entire frame buffer, just the parts that changed, which can be very small even at 8k - e.g. the box of a checkbox being switched
- ben-schaaf 4y ago
  Scrolling requires redrawing most if not the whole framebuffer.
  - HideousKojima 4y ago
    With scrolling couldn't you just shift the existing framebuffer up/down and only draw the newly scrolled-to parts?
    - kevingadd 4y ago
      The GPU buffering model doesn't usually let you read the previous frame like that these days, so you would need a scratch surface. That increases your bandwidth and memory requirements, so shifting doesn't end up being much faster if it's faster at all.
      - TylerE 4y ago
        I suspect there are enough edge cases (semi-transparent things jumps to mind) that it's unlikely to be lossless, anyway.
- kllrnohj 4y ago
  You don't need to redraw the entire framebuffer with GPU rendering, either. It's perfectly possible to do small, partial updates. See for example https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_buffer_age.txt https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_buff... And https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_partial_update.txt https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_part...
CyberDildonics 4y ago
You aren't talking about the same thing they are and you aren't talking about a scenario that exists. 8k is still exotic and no one is driving any desktop off of a video buffer going from main memory through a CPU.
- ben-schaaf 4y ago
  We've literally got an 8k screen in the office and 4k is becoming increasingly common. Not only is this a scenario that exists it's one I've personally experienced and fixed.
  - CyberDildonics 4y ago
    Your 8k screen is run purely off of the CPU drawing to a frame buffer?

fxtentacle 4y ago

You are correct, but so is the comment you replied to. The latency that matters for a text editor is how long it takes for a new keypress to show up. And that's usually a 32x32 pixel area or less.

gizmo 4y ago
That's not sufficient, though. You want the 0.1% case where you press undo a couple of times and big edit operations get reversed to be smooth. You have to hit your frame target when a lot is happening, the individual key press case is easy. It's just like a video game. A consistent 60fps is much better than an average frame rate of 120fps that drops to 15fps when the shooting starts and things get blown up. You spend all the time optimizing for the worst case where all your caches get invalidated at the same time.
- fxtentacle 4y ago
  In a video game, you'd just blur the shit out of everything else while you grant yourself a 2nd frame to re-render the rest of the content [1]. Or you do temporal remapping like the Oculus does if you rotate your head too quickly. [1] https://developer.nvidia.com/blog/nvidia-vrss-2-dynamic-foveated-rendering-no-assembly-required/ https://developer.nvidia.com/blog/nvidia-vrss-2-dynamic-fove...
ben-schaaf 4y ago
The other latency that matters is how long it takes to draw each frame when scrolling through the code, which is usually most if not all of the framebuffer.
- fxtentacle 4y ago
  Agree. In that case, you need to cache the result of your CPU rendering in a GPU texture so that you can smoothly scroll it. But you can probably still get away with drawing all UI components on the CPU if you add a little bit of caching.

jcelerier 4y ago

But when you do software rendering you don't need to redraw the entire frame buffer, just the parts that changed, which can be very small even at 8k - e.g. the box of a checkbox being switched

ben-schaaf 4y ago
Scrolling requires redrawing most if not the whole framebuffer.
- HideousKojima 4y ago
  With scrolling couldn't you just shift the existing framebuffer up/down and only draw the newly scrolled-to parts?
  - kevingadd 4y ago
    The GPU buffering model doesn't usually let you read the previous frame like that these days, so you would need a scratch surface. That increases your bandwidth and memory requirements, so shifting doesn't end up being much faster if it's faster at all.
    - TylerE 4y ago
      I suspect there are enough edge cases (semi-transparent things jumps to mind) that it's unlikely to be lossless, anyway.
kllrnohj 4y ago
You don't need to redraw the entire framebuffer with GPU rendering, either. It's perfectly possible to do small, partial updates. See for example https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_buffer_age.txt https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_buff... And https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_partial_update.txt https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_part...

CyberDildonics 4y ago

You aren't talking about the same thing they are and you aren't talking about a scenario that exists. 8k is still exotic and no one is driving any desktop off of a video buffer going from main memory through a CPU.

ben-schaaf 4y ago
We've literally got an 8k screen in the office and 4k is becoming increasingly common. Not only is this a scenario that exists it's one I've personally experienced and fixed.
- CyberDildonics 4y ago
  Your 8k screen is run purely off of the CPU drawing to a frame buffer?