[Performance] Only add 3d acceleration onto elements that actually scroll

[matthew-andrews]

I know we add uses3d-esque hacks onto FT scroller elements to push the scroll rendering onto the GPU but that feels a little wasteful in cases where FT Scroller knows that that element will never scroll.

To recreate:

• use Chrome's to "Show Composited layer borders" to identify the hardware accelerated layers. (Remove all of the ones on the accordions)
• Give the FT scroller element and accordion title ids so you can trigger events / manipulate properties on them with JS to prevent timeline getting filled with noise.
• Use timeline to record, run the commands show in screenshot into the console.

Conclusion: don't make layers unnecessarily.

[rowanbeentje]

Ooh. Tricky one. To implement this we have two options:

1. Dynamically add and remove the class that enables 3d acceleration as elements are detected to be scrollable or not, on startup and dimension change. The disadvantage to doing this is that adding or removing the class will cause a relayout, almost certainly a non-coalescing one because it has to happen after a height read.
2. Not adding the acceleration until it becomes time to trigger a scroll. Depending on the way the acceleration is added, this may cause a layout on start of scroll (bad, and something we just managed to get rid of) and will almost certainly cause a flicker as the element moves from being non-accelerated to being accelerated...

[rowanbeentje]

(In this particular case, we could also just not add a scroller if we deem it to be unnecessary...)

[matthew-andrews]

1. is my preferred option - the issue you raised could be mitigated via batching them a la FastDom? The classes of active scrollers in the dom could be added/removed at the same time.
2. less keen - this could have the potential of janking just as you start scrolling couldn't it?
3. This would be equivalent to 1 wouldn't it? But on slightly haphazard / case by case basis...