Re: Proposal: will-animate property

On Thu, Dec 5, 2013 at 11:18 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Dec 6, 2013 at 6:09 AM, Ali Juma <ajuma@chromium.org> wrote:
>
>> On Wed, Dec 4, 2013 at 8:57 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> I understand what you've said, but it seems a little abstract to me.
>>>
>>> Can we just defer the introduction of "will-animate:positioning" until
>>> we have a more concrete use-case for it, and a stronger argument that
>>> alternatives such as automatic inference for that use-case are not tenable?
>>> We can easily add it later if we need it.
>>>
>>
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 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.



> 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?