Hacker News new | ask | show | jobs
by dictum 4346 days ago
Here's something that's been bothering me since Chrome dropped the experimental support for `position: sticky` (and CSS Regions before) and I didn't find the right place to ask (nor is a submission about the JS engine an appropriate venue for this question, I know), so I'm going to hijack this thread:

We know some properties are expensive and when you use them a few times (or with certain values) you get sub-60fps scrolling — but why are they expensive? Are they inherently hard to optimize (e.g. different GPUs across mobile devices), or is it that nobody got to optimize them yet?

2 comments

Because, in general, they can trigger layout/reflow, so they can't run on the compositor. For example, changing things like "top" on an absolutely positioned box can trigger reflow of the contents inside, because of the way CSS works (for example, if "bottom" is set, then the height changes, which can affect the size of things with percentage heights, which can cause floats to be repositioned, etc. etc.)

In traditional browser engines it's even worse because layout runs on the main thread, which is also shared with your JavaScript, so painting ends up transitively blocked waiting for your scripts to finish. That is not the case in Servo (disclaimer: I work on Servo), but making layout run off the main thread is hard for many reasons—some inherent to the problem, some historical in the design of current engines—so all current browsers run JS and layout together.

Exactly.

To elaborate on how this works in Gecko. The rendering pipeline has several optional stages:

requestAnimationFrame (Scripts) -> Style flush -> Reflow flush -> display list construction -> Layer construction (recycling) -> invalidation -> Paint/Rasterization -> Compositing (on it's own thread).

Gecko tries to only run each stage of the pipeline only if they are needed. Fast operations like a CSS transition on an opacity or transform will only activate the Compositing phase. WebGL only canvas drawing will only activate rAF + Compositing. Meanwhile a JS animation on "top" will run all of these phases.

> Because, in general, they can trigger layout/reflow, so they can't run on the compositor.

If you're doing absolute layout, it's easier/better performing to just set top/left to zero, set width and height to their correct values, and then use CSS transforms to position the element where you want it on the page. :)

(Not meant for you, pcwalton, but for others who might not know about a reasonable workaround.)

I hadn't heard of Servo until just now, googled it and it looks really neat.

Could you elaborate on what things you think Servo does better than current rendering engines?

I am going to hijack your hijacked thread:

I wrote a [jquery plugin](http://mkoryak.github.io/floatThead/) that 'simulates' `position:sticky` on table headers.