Glad we solved glitchy scrolling for now (the title of this blog post was “on rendering diffs”, not “searching diffs”). Browser search on a 36 million line diff would not by great, but it’s something we hope to have a solution for. One step at a time.
Would love to see a website that makes everything DiffsHub does without making any of the work necessary. Making it all obsolete would be a huge step forward for the web. We support diffs that exceed 36 million lines, with syntax highlighting, comments, bundled into a reusable library for anyone to use.
Also this works in all browsers, fixing blink doesn’t help move the web forward.
I probably didn’t explain this well enough, but your render times always have to be within the frame buffer (16.6ms for 60hz or 8.3ms for 120hz). Under normal circumstances even if you occasionally blow a frame buffer, with the over-scroll you won’t hit the sticky bounds.
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.
> disagree with the theory that scrolling frame rate doesn't need to be smooth for scrolling to feel smooth
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.
Naw, the truth is I'm not really smart or intelligent enough to build a semantic diff system. For that you'll need to wait on a post from one of our smarter devs, this was a post about rendering diffs in a browser.
Yes and no. It would help to improve things a bit when it comes the measure/reconciliation phase (unclear to say how much). However we've already done a pretty good job around batching writes vs reads.
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
Performance and optimization is one of many pieces, but yes, it's a meme to render 500k lines.
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.
One of our next big projects is actually to support semantic diffs, which I think will be a lot more applicable to what you're asking for here. Currently diffs just takes a normal git patch file, or generates one from 2 versions of a file.