Also this works in all browsers, fixing blink doesn’t help move the web forward.

The only time you will is if you’re scrolling at a rate where the jumps are quite large — large and fast enough typically where you’re not going to have a frame of reference for what you should see vs what you are seeing to notice you are behind.

Ultimately scrolling is managed on a separate thread from JS, which means if you do like an opt+click on the scroll bar, you’re going to make a jump that JavaScript can never keep up with, even if you’re under your frame times.

And with regards to safari, if your requestAnimationFrame is capped at 60hz but your scrolling is GPU composited at 120hz, this is the only way to keep scrolling at 120hz with 60hz dom updates and never see any blanking.

Just to be clear tho, we don't actually scroll jack, native scrolling works as it should and content should move with normal gpu composited scroll. That said, it's possible that loading that much data into memory may be causing causing knock on effects somehow that are just slowing everything down.

It's possible you might be misunderstanding what I was trying to say here because 120hz scrolling on a 120hz device was the goal and why one of those virtualization techniques was not acceptable to me which lead me to coming up with a novel workaround to this problem (Inverse Sticky Technique).

CodeView uses a system that allows scrolling to update at your native framerate (120hz) WITHOUT needing Javascript needing to keep up at 120hz. If you're seeing stuttering while scrolling on https://diffshub.com would love to know more context (device/diff link/etc) because that is very much NOT our experience.

However passing a million lines of code through pretext is unlikely to be very efficient, so a lot of the work around estimation is still very important.

That said, while I don't want to make pretext a direct dependency of the library, there's a good chance I'll explore the possibility of allowing devs to pass it in as an additional argument perhaps improve performance a bit.

It should also be noted that we have a full API to support things like line annotations (comments, etc) that are entirely controlled by the user, so there's always a bit of a dynamic aspect there that would come into play

That said though, and maybe I didn't say it well in the post, the more performant and optimized your tool is, the less burden you put on developers and users.

Sure you won't review 100k lines, but maybe the diff includes a ton of testing snapshots, or maybe it's a long running feature branch and you need to just quickly jump in and look at a specific change from a specific file. The less the developer or the user needs to think about `how` to render the diff or `how to navigate the diff`, the better we did our job.

Comments URL: https://news.ycombinator.com/item?id=48327809

Points: 194

# Comments: 65

Discord works in a browser or with the native apps. Just visit the website and click 'Open Discord in your browser'

It's getting old.

Comments URL: https://news.ycombinator.com/item?id=8106695

Points: 3

# Comments: 0