Re: Proposal: will-animate property

On Fri, Dec 6, 2013 at 7:27 PM, Nat Duca <nduca@chromium.org> wrote:

> I'm sorry if I gave you the impression that this was hypothetical. Our #1
> thing we do for content to make it smoother is to fix bugs with moving or
> sizing elements not getting layers.
>
> There are simply so many ways for authors to reposition elements every
> frame without us knowing in advance that it will happen, or even knowing
> when they've stopped repositioning it again.
>
> jQuery, to this day, still does all its positioning with script, and
> rarely with css transforms. This means the vast majority of JQ animations
> are either:
> - janky throughout because we don't create layers for them, or
>
> - if the author uses translate3d on the animation, then have a long first
> frame because the first frame is when we realize that the thing is moving
> and we have to pop the animating item out. This implies a repaint, which
> often takes 50s of ms on mobile.
>
> Some folks try to get clever:
> - translateZ(0) when the element is not moving, as a way to trick a layer
> But then they do a 2d animation... using translate2d(x,y). This causes the
> element to lose its stacking context, triggering a repaint and possibly
> other unexpected behaviors.
>
> Any browser that bakes content to layers would benefit from explicit
> statement of movement, I think. Am I missing something here?
>

I've done some work on optimizing jQuery-driven pages recently. Those pages
were animating top/left/margin-left/margin-right. We detect scripted
animations of those properties and layerize. For those pages,
will-animate:top/left/margin-left/margin-right can avoid the initial paint
problem. So I'm totally on board with "explicit statement of movement" via
will-animate:transform/top/left/margin-left/margin-right (and others). I'm
just trying to understand the need for "will-animate:positioning" divorced
from any property on the element.


>
>>  I think the use case is situations like [1], where the actual animation
>>> is on the green box, but layerizing the blue boxes (which are effectively
>>> being moved) using the translateZ hack gives a roughly 10X speed up in
>>> paint time for Blink (specifically, paint time goes from roughly
>>> 1.5ms/frame to 0.15ms/frame on my Linux desktop).
>>>
>>
> This was motivated by a fly-in mockup of a results page... think, say,
> search results flying in from the bottom of the page. The prototype happens
> to loop.
>
> There are many ways to accomplish a fly-in effect. For instance, you can
> make it a block flow and fly it in or out with a 3D transform. But, as I
> noted before, folks often forget to keep the transform on when its not
> moving, meaning that there's a repaint at the beginning and end.
>

For a block flying in with a transform, "will-animate:transform" will work
nicely.

I'm interested in examples where the animated scene cannot easily be
constructed by animating properties of the element that is moving, and the
elements that will move cannot easily be identified once we know the
elements whose properties will change, thus requiring use of
"will-animate:positioning".

Let me try to be more helpful. In your example [1], we can imagine that
there are many blue boxes so it's burdensome to annotate them all with
their own positioning/transforms, and let's suppose for the sake of
argument that we can't put the blue boxes in their own container and
animate that (a claim that would be easier to sustain if we had more
details of a realistic use-case). Then one question is, if we just specify
'will-animate:height' on the green box, could a browser reasonably infer
the necessary layerization of the blue boxes? Personally I think it could.
It doesn't seem difficult to walk the render tree and identify the elements
whose positions are likely to change when the height of the green box
changes. So I don't feel [1] motivates the addition of
will-animate:positioning.

(Interestingly, in that case, the browser can deduce more useful
information than it would get from will-animate:positioning on the blue
boxes. The browser can infer that the blue boxes will all move together and
can therefore be in the same layer, whereas will-animate:positioning on the
blue boxes would suggest that they can move independently and therefore
shouldn't be in the same layer.)


> When introducing the a new feature, there is a burden of proof (for a low
>> standard of "proof" :-) ) that it can't be done automatically, not the
>> other way around.
>>
>
> By this standard, can you please justify for us why you can't compute
> will-animate: scroll from overflow state?
>

Sure. Some pages have a lot of overflow:auto elements but don't expect any
particular element to be scrolled by the user (e.g. a page with a lot of
overflow:auto code samples). Other pages have one particular element that
the user is very likely to scroll (e.g. an element whose content is
particularly important to the user). It's very difficult to distinguish
these cases using heuristics.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w