logoalt Hacker News

gloria_mundi • today at 1:29 AM • 3 replies • view on HN

I don't understand the point of the inverse sticky technique. Scrolling too fast still breaks the experience (content refuses to scroll), and in a way that, at least to me, feels more disruptive than blanking for a fraction of a second. I might just be too used to blanking.

Also ... shouldn't browsers just be able to render the diff without any of the trickery? Is the browser's job actually that hard for long pages, or are they just not optimising for this? Or is there some other reason for the virtualisation (e.g. memory usage)?

Replies

amadeus • today at 1:54 AM

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.

Joker_vD • today at 10:47 AM

Also, I am deeply suspicious if they can properly support searching with Ctrl+F...

And yes, browsers should be just able to render the diffs, if the styling is somewhat minimal and there is no JS: I have a 6.3-MiB large HTML file with complete transcript of a certain TV series, formatted like

    <dd><b>Character #1</b>: Well, that was interesting all right.</dd>
    <dd><b>Character #2</b>: [sigh]</dd></dl>
    <dl><dd><b>Character #1</b>: Lemme help you.</dd>
    <dd><b>Character #3</b>: Yeehaw!</dd>
    <dd>[thump]</dd>
(the </dl><dl> produces a small paragraph break, to indicate scene transitions), and it scrolls and searches just fine.
shay_ker • today at 4:37 AM

hmm it does seem like a good point that browsers should be able to do this natively. the DOM already holds the content, and browsers manage what's rendered in the viewport.