Re: Proposal: will-animate property

On Wed, Dec 4, 2013 at 2:00 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Dec 5, 2013 at 10:35 AM, Ali Juma <ajuma@chromium.org> wrote:
>
>> In these situations, it would be ideal if authors could simply specify
>> the appropriate "will-animate" property on the green box, and have
>> implementations infer the effect on the blue boxes. But my understanding is
>> that this sort of inference is, in general, too expensive to compute
>> on-the-fly.
>>
>
> Why?
>

This gets back to the topic that motivated the containment proposal: to get
great performance, you need (a) layers, and whenever possible (b) to make
the work required for rendering be ~= viewport in size, rather than ~=
document in size. This is why we paint only the visible parts of layers,
for instance. Containment lets us defer large portions of style & layout
for off-viewport, which is one of the reasons we were poking at it in the
first place.

So, bringing it back to layers. Suppose we now have this nicely contained
world, where we've deferred work whenever possible. Now, we have a div that
we think is going to be onscreen and we want to know if its likely to move
or change. So now we have to go get styling info for anyone that can effect
our position. The concern here is that this will undo the optimizations
we're seeking to establish footholds for in the containment space.


>
>
>> The other issue is what to do when a property in the will-animate list is
>> one that's inherited (e.g. color, font-size). Should "will-animate" be
>> inherited too in this case (since the animation itself will be)?
>>
>
> The UA can determine whether the changing font-size of the will-animate
> element will be inherited. We don't need to explicitly inherit will-animate
> as well.
>

The concern here is twofold:
1) the basic the cost of this [its more work than just saying "you've set
this style"] and
2) the the number of elements that need to be considered in order to make
this determination.

It seems to me that there are many situations that can be constructed where
a significant portion of the document can end up influencing whether a div
is likely to move or resize, which then means that the cost of using
will-animate for this purpose becomes steeper.


As an example, http://jsbin.com/UVIgUTa/6/quiet is a "poor mans" hack of
iOS7's message app, where each message moves independently. Style recalc
for us in this takes a whopping 4ms for 12 messages, and e.g.
http://aerotwist.com/static/blog/bad-benchmark-right-result/strings.png.
Full writeup on scaling as element count grows here at
http://aerotwist.com/blog/bad-benchmark-right-result/.

Now, it definitely is true that the per-element cost and thus slopes of
these charts are higher than they should be in Blink. But, even if we get
those in line somehow and get a 10x reduction in costs, we're still looking
at 4 and 5ms of work for quite-reasonably-sized document just in the cost
of style engine. That's at the upper bound of plausibility: the other parts
of the rendering pipeline also need time: on a Nexus 4 with Chrome 32, a
typical breakdown of the 16ms total is:
- 2ms to input, raf and onscroll
- 1ms to layout
- 6ms to painting/compositing & gpu stack
- 4ms to the OS [gl driver, window manager, etc]
- 1ms to noise: kernel scheduler, inter-process delays, etc
Hopefully that gives some context on why 4ms on recalc gets us worried:
with this above, we're at 14.

What we seek, with containment, and probably more in the future, is ways
for us to preserve the the ability of the web to have a document, but for
offscreen elements contribute less to the cost of each of the stages above.

+ojan, in case he has a way to say this in a clearer way.