@_chenglou
# Big Post On The Oddities of Frame Scheduling The mouse across all OSes have special hardware & GPU paths dedicated to it. This ensures that even when everything freezes, your mouse moves stay smooth. It’s one of the last thing to ever lag on your display. When you see the red square lag behind the cursor, you’re seeing the (minimum!) usual webapps lag vs the ground truth hardware-accelerated cursor. But even the ground truth lags. macOS actually has a higher input latency (both iOS and macOS are triple buffered, as opposed to double for Windows/Linux) because it prioritizes smoothness “correctness” over raw latency (ask chatgpt). Triple buffered = 3 frames, which is a lot, but with 120fps refresh rate like ProMotion, it’s less noticeable. On the other hand, webapps are in theory infinite frames behind because many use a timeout for coordinating certain logics instead of using frames. So 50ms timeout means 4 frames on 60hz, 7 frames on 120hz, and your favorite helper library for e.g. virtualization or whatever probably has some timeout somewhere so anything you do will pathologically have at least that much latency. cc @andy_matuschak Regarding scroll: yes the black items are actually lagging, just that there’s no reference on screen for comparison. The browser scroll event is fired async; they're the "most" async on Safari (thus on every iPhone, since every browser on iPhone is actually just a UI around Safari). This is why you see some random mobile site with a floating button/menu that jitters vertically as you scroll; those read the stale scrollTop value from the async scroll event and calculate an offset that's unsynced vs the scrolling view behind the floater. If you want to prioritize smoothness over raw latency, you'd in theory hand-update both the floater and your scroll UI's position (e.g. read from an invisible view's scrollTop and update the real visible view's scrollTop. And since the floater UI also uses the same wrong scrollTop, at least everything's wrong at the same time). This is very complex; plus Safari still caps JavaScript updates to 60fps by default. Btw scrollTop value is also wrongly truncated across different browsers by spec. I have a bigger tangent on scrolling in this messy half-finished repo here: https://t.co/XjJUqGAlpi cc @jordwalke. People flee to CSS to use one-off fixes but those don't cooperate with any of the JS for the above reasons Also requestAnimationFrame likely will add drawing problems. Chrome skips repaints: https://t.co/3LD2OPR7Hv and rAF scheduling is weirder than you think: https://t.co/fPHv5MbqTd. More info at https://t.co/oD5EOml3T9 And then React itself adds complexities. Here's a thread I've barely found back. Feel free to read or ignore it but I myself forgot half of the nuances there already: https://t.co/ZWTM6Le9pt https://t.co/ScHUR55KDs And on top of this, folks throw around useEffects for data syncing and now we're an arbitrary number of frames behind Related, some posts by @trishume on keyboard latency: https://t.co/ctXbxhlSZa https://t.co/a1J7dDkvXX