3 ms·

According to this: https://www.youtube.com/watch?v=BTURkjYJ_uk https://www.youtube.com/watch?v=BTURkjYJ_uk Firefox's servo engine can compose CSS elements/Disp

by srcmap 9y ago

According to this: https://www.youtube.com/watch?v=BTURkjYJ_uk https://www.youtube.com/watch?v=BTURkjYJ_uk Firefox's servo engine can compose CSS elements/Display List together at 500 frames / second. Maybe next version of Windows / Linux desktop should use FF's servo engine?

lukeschlather 9y ago
That's throughput, though, not latency. I would guess that servo's input latency is significantly more than 2ms, even if their throughput for certain rendering operations is 500 fps.
nwah1 9y ago
Depends on the complexity of the html and CSS in question. To reproduce a full desktop environment, even just using Canvas, would be challenging and I highly doubt it would allow 500fps.
bufferoverflow 9y ago
Don't confuse bandwidth and latency.
amaranth 9y ago
Your application renders a frame then the compositor gets it and does its transformations, if any. The composited result is then rendered to the screen thus adding one frame of latency. That's why the article says one solution would be to get a 144Hz monitor, it would reduce the time between frames so an extra frame of latency wouldn't be as bad. You could potentially reduce this delay as well by having the application and the compositor in communication. Since rendering is going to be synced to vblank if you can get the application to not try to sync as well and instead just notify the compositor when it is done drawing a frame you could potentially get the application drawing and the compositor drawing in the same vblank interval. This is what Wayland and DRI3 Present let you do in the Linux world, I assume Windows has something similar but you'd need to opt-in to it so I bet nothing uses it.
pcwalton 9y ago
Thanks for the kind words :) But that was an artificial benchmarking mode that turned off any synchronization. It couldn't actually show the picture at hundreds of FPS, because the physical hardware can only update at 60.
Iwan-Zotow 9y ago
"Money can buy bandwidth. Latency requires bribing God."

by srcmap 9y ago

lukeschlather 9y ago

That's throughput, though, not latency. I would guess that servo's input latency is significantly more than 2ms, even if their throughput for certain rendering operations is 500 fps.

nwah1 9y ago

Depends on the complexity of the html and CSS in question. To reproduce a full desktop environment, even just using Canvas, would be challenging and I highly doubt it would allow 500fps.

bufferoverflow 9y ago

Don't confuse bandwidth and latency.

amaranth 9y ago

Your application renders a frame then the compositor gets it and does its transformations, if any. The composited result is then rendered to the screen thus adding one frame of latency. That's why the article says one solution would be to get a 144Hz monitor, it would reduce the time between frames so an extra frame of latency wouldn't be as bad. You could potentially reduce this delay as well by having the application and the compositor in communication. Since rendering is going to be synced to vblank if you can get the application to not try to sync as well and instead just notify the compositor when it is done drawing a frame you could potentially get the application drawing and the compositor drawing in the same vblank interval. This is what Wayland and DRI3 Present let you do in the Linux world, I assume Windows has something similar but you'd need to opt-in to it so I bet nothing uses it.

pcwalton 9y ago

Thanks for the kind words :) But that was an artificial benchmarking mode that turned off any synchronization. It couldn't actually show the picture at hundreds of FPS, because the physical hardware can only update at 60.

Iwan-Zotow 9y ago

"Money can buy bandwidth. Latency requires bribing God."