Hacker News Reader

Comment by reissbaker | Hacker News Reader

Author here. The utility is just to improve scroll smoothness (aka repaint times) of very-expensive-to-render pages, like infinite feeds with nice CSS effects. If you check out the demos linked to on the page, the demo with Infinity turned off should be noticeably choppier than the demo with it on, even once it's completely loaded and the browser's stopped reflowing. Probably depends on your machine/OS/browser combination -- but it'll keep loading more pugs as you scroll down, and eventually the version with Infinity off will grind just about anything to a halt.

View on HN

For me, in chrome on win7, the on and off demos both appear to be about equally choppy. I doubt I could identify a difference in a blind test.

Strange. It's the other way around for me (brand new Win7 box, Chrome, 16gb ram, fast everything, waited for all images to load before scrolling).

When I move the scrollbar on the "on" version, it flashes white and constantly drops images in and out until I let go or stop in one place. Then it whites out again next time I scroll. Quite distracting actually, like viewing the bottom part of a long page while it's still loading images.

The "off" version scrolls as one would expect, no flashes, no missing or reflowing content. Just like you'd expect.

PgUp/PgDown and arrow keys don't seem any different between the two.

I did something almost exactly the same[1] for a design project at school a while back, where I explained why current infinite scrolling UX is not great and how something like this could help[2]. I'm glad someone made this into a library!

[1] http://newcoursys.herokuapp.com/courses/2012sp-cmpt-165-c1/a... [2] http://newcoursys.herokuapp.com/#marking-interface

By repaint times, do you mean re-layout times? ie. time required for CSS/HTML/JS to determine where to paint to?

The demo is not any smoother on my 27" Apple display driven by a late 2010 model MacBook air. However, even low res hardware accelerated video renders choppy at large window sizes (although perf gets better when VLC or QuickTime is true fullscreen; presumably the compositor is off)

Faster JavaScript is unlikely to be effective at enhancing buffer flip times, which (for me) dominate repaint times.

Both repaints and relayouts are improved, actually. The faster repaints are what improves scrolling performance (repaints are triggered every time you scroll, but relayouts are not) -- but because there are fewer elements in the DOM tree, relayouts are cheaper as well.

We experimented with using display:none instead of removing the elements; it increased scrolling performance just as much as actual element removal, but the relayouts when new content was appended got to be prohibitively expensive once a certain amount of content was loaded (literally pausing the browser for a noticeable amount of time), because the browser still had to traverse a giant tree of HTML entities during the relayout. So even if the buffer flip times are still too slow for you to get completely smooth scrolling in complex demos like this -- and that makes sense, given your large-screen setup -- you'll hopefully still benefit some from the faster, non-browser-freezing relayouts.

Both repaints and relayouts are improved, actually.

When actually is defined as for some on certain machines, judging from the number of directly contradictory observations in this thread.

The word "actually" ought to be reserved for concrete facts with zero counter examples.

The word "hopefully" in your closing sentence seems more apt.

That said, very much appreciate the sharing of the hypothesis and implementation. It's great to see ideas from other areas (video game terrain feature pop in) leveraged to improve end users' browsing experience.

Reply on news.ycombinator.com