3 ms·

> On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. Sure, 500 fps, but that's not the important part

> On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. Sure, 500 fps, but that's not the important part. Latency would be. So at 500 fps with how much output latency to the display?

c-smile 9y ago
For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate). Editor keeps each line in separate <text> DOM elements (like <p> but no margins and only text inside). So we just need to relayout one particular line in order to show typed character.
- vardump 9y ago
  > For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate). That's very impressive, if so. On Windows 7 with DWM (GPU display compositor) switched off? How did you validate and measure latency? Someone correct me if I'm wrong, but I'm under impression Windows 10 DWM adds additional latency making 16 ms latency unachievable.
  - c-smile 9y ago
    Not sure I understand your concerns. If you have DirectX there then you will have the same GPU rendering. If that's about CPU rasterizers then Direct2D/WARP and Skia rasterizers are pretty good. Problem is that if you have two monitors of the same size but one of "standard" 96ppi and another is, say, Retina grade (300+ ppi) then GPU rendering is the only reasonable option. Number of pixels to rasterize is 9 times more in Retina case. We do not have CPU performance increased 9 times...
kllrnohj 9y ago
It would be dependent on how deep the pipeline is. In the fairly common case of 1 to 2 app threads (ui + rendering) + GPU work you're looking at a pipeline depth of 3, so if it's doing 500fps that must mean no stage of the pipeline is taking longer than 2ms. With 3 pipeline stages that puts your worst-case latency at 6ms.

3 ms·

> On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. Sure, 500 fps, but that's not the important part

by vardump 9y ago

c-smile 9y ago
For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate). Editor keeps each line in separate <text> DOM elements (like <p> but no margins and only text inside). So we just need to relayout one particular line in order to show typed character.
- vardump 9y ago
  > For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate). That's very impressive, if so. On Windows 7 with DWM (GPU display compositor) switched off? How did you validate and measure latency? Someone correct me if I'm wrong, but I'm under impression Windows 10 DWM adds additional latency making 16 ms latency unachievable.
  - c-smile 9y ago
    Not sure I understand your concerns. If you have DirectX there then you will have the same GPU rendering. If that's about CPU rasterizers then Direct2D/WARP and Skia rasterizers are pretty good. Problem is that if you have two monitors of the same size but one of "standard" 96ppi and another is, say, Retina grade (300+ ppi) then GPU rendering is the only reasonable option. Number of pixels to rasterize is 9 times more in Retina case. We do not have CPU performance increased 9 times...
kllrnohj 9y ago
It would be dependent on how deep the pipeline is. In the fairly common case of 1 to 2 app threads (ui + rendering) + GPU work you're looking at a pipeline depth of 3, so if it's doing 500fps that must mean no stage of the pipeline is taking longer than 2ms. With 3 pipeline stages that puts your worst-case latency at 6ms.