On 10/6/14 7:14 PM, Josh Matthews wrote:
Could you clarify how CSS animations and transitions are related here?
Sure. For optimum performance, browsers with accelerated and
off-main-thread compositing have traditionally run a subset of CSS
animations/transitions (those that require no complex layout) on the
compositor thread. Specifically, this subset is CSS animations and
transforms that affect only 2D and 3D transforms and opacity, although
there may be more such properties nowadays. The reason this is done is
for smoother performance by avoiding having to hit the main thread,
since the main thread in extant browser engines is highly contended with
JavaScript execution, GC, style recalc, and layout.
I wouldn't be surprised if this matters less in Servo, because layout
for CSS animations happens in a different thread from JS execution and
GC. However, style recalc and layout coming from JavaScript could still
cause CSS animations and transitions to stall, so I suspect it's still
worth doing.
It may be worth thinking about how to either expand this set of magic
accelerated-animatable properties or to somehow allow style recalc
initiated by the DOM to run concurrently with CSS animations. The reason
is that Web authors have a lot of incentives to animate by adjusting
absolute/relative position properties just because it's a lot easier to
type "top" than to think about transforms. Popular frameworks like
jQuery reinforce this [1], although just solving this problem won't
fully fix the issue because Web authors also tend to use `setTimeout()`
for animations a lot...
Patrick
[1]: Notice, for example, that the official documentation for jQuery
`.animate()` at http://api.jquery.com/animate/ animates `height`, which
is very much not layerizable in all cases.
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
