Rendering is fast on Chrome, however latency is high:
Chrome has 1 to 2 frames (17ms to 33ms on a 60Hz display) of additional, unnecessary input lag when compared to Firefox:
https://bugs.chromium.org/p/chromium/issues/detail?id=460919
Chrome has 1 to 2 frames (17ms to 33ms on a 60Hz display) of additional, unnecessary input lag when compared to Firefox:
https://bugs.chromium.org/p/chromium/issues/detail?id=460919
[1] https://www.vsynctester.com/
[2] https://phoboslab.org/log/2012/06/measuring-input-lag-in-bro...
Like switching to the Classic Theme from Aero in Windows 7[1], as far as I can tell, this removes at minimum 1-2 frames of input lag (typing, mouse movement, etc.) throughout all of macOS.
In Firefox's about:config, after setting
user_pref("accessibility.force_disabled", 1) user_pref("general.smoothScroll", false) user_pref("general.autoScroll", true)
, I'm shocked by just how slow and laggy Chrome's builtin smooth scrolling implementation feels by comparison. In fact, it's so bad that I now open Chrome and all Electron apps with
open -a Google\ Chrome --args --disable-smooth-scrolling --disable-gpu-vsync --disable-frame-rate-limit open -a Slack --args --disable-smooth-scrolling open -a Spotify --args --disable-smooth-scrolling
You used to be able to disable Chrome's smooth scrolling with chrome://flags/#disable-smooth-scrolling, but that flag was removed for whatever reason.
I'm also surprised by how much faster Firefox's builtin middle mouse click autoscroll is compared to Chrome's ersatz AutoScroll[2] extension.
[0]: https://download.developer.apple.com/Developer_Tools/Additio...
[1]: https://pavelfatin.com/typometer/
[2]: https://chrome.google.com/webstore/detail/autoscroll/occjjkg...
Are you using a >120Hz Monitor or don't you care about the occasional tearing?
I don't mind the occasional tearing — I usually only notice it when using autoscroll in Firefox at a lower speed/velocity.
As a remote SWE, I sit in front of my computer all day every day, so I find that the benefit in speed I get from removing at least one frame of input lag outweighs the occasional tearing which occurs as a result. I'm not exactly sure why, but I haven't noticed any tearing when playing video content.
I also spend a lot of time in XQuartz, which has some longstanding rendering bugs unless you disable vsync.
user_pref("accessibility.force_disabled", 1)
user_pref("general.smoothScroll", false)
user_pref("general.autoScroll", true)
---
# --disable-frame-rate-limit is buggy on macOS
open -a Google\ Chrome --args --disable-gpu-vsync --disable-smooth-scrolling
open -a Slack --args --disable-frame-rate-limit --disable-gpu-vsync --disable-smooth-scrolling
open -a Spotify --args --disable-frame-rate-limit --disable-gpu-vsync --disable-smooth-scrolling
https://developers.google.com/web/updates/2019/05/desynchron...
We added this for low latency drawing in Keep and Chrome Canvas and the ChromeOS PDF annotation mode.
AFAIK DWM is the main culprit here (1-2 frames) and `desynchronized` does not circumvent it (but avoids at best 1 frame of canvas vs DOM synchronization).
I'm pretty sure that's what most games use to bypass the forced DWM vsync. For example, when I used Dolphin on one of those cheap 60hz IPS LCD monitors with no internal scaler, I always preferred the lower latency + tearing in exclusive fullscreen compared to the laggy + smooth windowed mode. There was honestly such a stark difference between the two that I found the game to be unplayable in DWM's windowed vsync mode.
[0]: https://devblogs.microsoft.com/directx/demystifying-full-scr...
edit: to answer my own question, it looks like Chrome does not use exclusive fullscreen https://news.ycombinator.com/item?id=28784108
It has complex and non-obvious effects. greggman on the three.js issue wrote a really nice summary on why it shouldn't be the default.
It's really only appropriate for highly latency sensitive applications, like drawing or certain games.
Modern GPUs have staggered rendering where one frame is rendered while the previous frame is postprocessed (that's a bit simplified, it's more like a waterfall with a bunch of different steps). That sort of a conveyor belt-like operation always induces latency, and a struggling GPU increases the time it takes the frame to hit the screen. We blame the frame rate, but in reality that's just another symptom of what's causing the perception of sluggishness, rather than the cause itself.
Display latency from LCDs are another factor - something that was completely absence on CRTs.
Picture the rendering process like a conveyor belt factory. This is a bit of a simplified model, GPUs are incredibly complex and things aren't quite this straightforward, but it's good enough way of reasoning about how they operate by imagining something like Factorio.
First you load up a scene, and then it goes into one machine that does the first part of the rendering, then the next machine does the next part, and so on and so forth, until it arrives at the other end and is drawn on the screen.
It's easy to see you can start working on the next frame while the first frame is in the second machine and that's probably in general a good idea.
Reducing how many items are on the belt doesn't reduce the time it takes to go from start to finish (i.e. the latency), it still has to go through the same steps. Loading up more items on the belt at the same (probably) improves the stability of the framerate, but again it does nothing for latency. If you load up too much on the belt may cause problems, but such a condition is easy enough to determine and avoid programmatically. The frames still take the same time to go from start to finish.
Bottom line is that the time between frames and the time to render a frame are disconnected, if they seem connected it's because getting a better GPU increases them both. But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency.
In game engines, long frame pipelines were all the rage in the early 2000's to distribute work across CPU cores without having to rewrite entire single-threaded systems to multithreading (so you might have a pipeline of input-, AI-, physics- and render-thread, each adding one frame of latency).
But that's also when "input latency" became a problem, so game engines went away from this pipeline architecture and ran all those steps in a single frame by parallelizing within systems, but still chaining the inputs and output of those big systems together in a linear sequence (but all ideally within one frame).
After that came the general task schedulers, where everything that needs to happen in one frame is split into very small tasks arranged in a dependency tree, and those small tasks are run by a general task scheduler running on a thread pool (sometimes even on the GPU).
The general goal is to distribute the same work across available CPU and GPU resources, but without introducing a deep frame pipeline, and for the only reason to reduce button-to-screen latency (while still cramming as much work as possible/needed onto the CPU and GPU).
This is not correct:
If your application frame rate is higher than your display refresh rate, triple buffering has lower latencies than double buffering. This is due to much more frames being rendered (and most of them discarded) so that the average age of the last frame rendered before being sent to the display is much younger (but never older) as in double buffering.
In terms of latency: VSYNC off < Triple Buffering < Double Buffering.
This pipeline: https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overv...
This is an important point. A 120Hz refresh rate causes _at least_ a worst-case latency of 8ms. People often drop the "at least" or ignore that latency compounds across the pipeline.
In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency).
> You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time.
True, if your system is not maxed out, you can enable Triple Buffering. If your rendering framerate is higher than your display, it will discard obsolete frames and only push the most recent one to the display.
Yes, that. Should have been more careful with my words - i.e. I meant latency of 1 frame due to the render ahead queue.
Not for me. When scrolling in Firefox I see pauses of about 0.5 seconds every 10 seconds or so, on all websites. After the end of each pause, scroll position jumps, as if the rendered suddenly catches up with the target position.
Similar pauses when entering text in a form
I tried playing agar.io on Firefox 93 a few days ago and it was unplayably janky.
I've been using Firefox for 20 years. This problem arrived in the last year, roughly, and has been annoyingly consistent since it arrived.
I don't like Chrome. But it feels more fluid to use because I've never noticed this level of periodic stalls. It has the feel of a difference in garbage collection strategy.
https://www.youtube.com/watch?v=YR0vNs0ZdWI
Not sure how it behaves on windowed modes. For instance, Doom Eternal's fullscreen is actually composited on the desktop (could be a Vulkan thing), but doesn't seem to suffer from DWM overhead, latency wise.