Janky scrolling (under 60fps)


(Jo Liss) #1

You probably know this already, but I figured it might still be worth opening a topic about this: Scrolling discussion pages in Chrome is janky. It seems to happen on any topic pages, but it’s easiest to see on lengthy topics.

This might be non-trivial to fix. It seems related to the way Discourse implements infinite scrolling, as Ember views are being rendered while scrolling.

Maybe the performance improvements coming down the pike with HTMLBars will alleviate some of this (I hear it’s 2-3x performance), but it will still be hard to consistently get under 16ms.

Twitter seems to be doing an OK job at 60fps infinite scrolling. Maybe we can learn from them.

(There is an old thread about Discourse scrolling performance, but I didn’t want to resurrect it…)


Slow scrolling in Chrome due to replaceState bug
(Jeff Atwood) #2

Hmm, doesn’t feel particularly unresponsive to me. Have you tried it on good hardware accelerated touch hardware, e.g. Surface 2 Pro and IE11, or iPad 4/5 and Mobile Safari?

http://try.discourse.org/t/discussion-happens-so-much/127

I love Chrome but it’s pretty terrible at hardware accelerated scrolling in general. I also wonder if the behavior is the same under Windows, there are sometimes big differences per platform when it comes to smooth scrolling.


(Jo Liss) #3

Chrome on Android looks like it gets 60fps, though most of the time the page is mostly white while scrolling. I assume this is because Ember Post views are taking some time to render, and mobile Chrome doesn’t block scrolling on JS execution. Don’t have an iPad around to try.

Desktop Firefox is janky like desktop Chrome by the way.


(Kane York) #4

There’s a bunch of hardware scrolling-related things at chrome://flags/.

Standard warning that some of these may break your browser experience, and that you need to relaunch the entire browser each time you change them. Void where prohibited. Some assembly required. Batteries not included. Contents may settle during shipment. Use only as directed. No other warranty expressed or implied. Freshest if eaten before date on carton. Driver does not carry cash. Avoid contact with eyes and skin and avoid inhaling fumes. It’s always darkest before the dawn. I am beating a dead horse with this :–P


(Sam Saffron) #5

This is clearly rendering related, look at console @eviltrout added logging , we are spending 5-15ms on my powerful desktop rendering each post.

I would like to hold off on HTMLBars that is meant to be many times faster than current rendering and also has a much leaner DOM.

Let’s see where it takes us and revisit then.

Short of that moving to a much more manual post render could help, but would complicate the code a fair bit.

cc @wycats


(Robin Ward) #6

I honestly don’t notice the jankiness on my desktop, but it comes up enough that I consider it an issue.

It is definitely more pronounced now that we cloak views, so we might be able to fix it by increasing the slack ratio on desktop to render less.

However, I am also excited for HTMLBars. Some early experiments I’ve done are quite positive with respect to replacing our string based rendering with DOM manipulation. I think we can probably table this until that comes out like @sam suggested. I’d hate to do a bunch of splunking only to find those parts of Ember replaced in a couple of months.


(Sam Saffron) #7

I just made some minor improvements, how does this compare to what you used to see?


(Jo Liss) #8

Cool! As for difference, hm, too hard to tell for me. I didn’t have a numeric benchmark to quantify the jankiness either, or I could compare more easily.


(Jeff Atwood) #9

How about now? I know one serious problem was the changing of the URL (to reflect position) during scroll, which on Chrome (only) forced a favicon reload – kind of a bug. We only change the URL on browser idle now rather than as scrolling occurs.

I believe there have been a few Ember upgrades since then as well.