Re: Proposal: will-animate property

I think this is a good idea. More complex animations, like the ones you
show, can benefit from using a different render than static content. Some
renders perform better at rendering static content (lower latency, memory
usage), while some renders need to build caches and intermediate
representations but will perform better once these are ready.

That said I have some reservations. For example your testcase (
http://jsfiddle.net/vBQHH/3/) might benefit from a will-animate: volatile
in one implementation but in gecko would instead be better represented as 1
active layers, the moving image, and a mask layer, the growing clip, not
require any rasterization and thus not be volatile (At least in theory, we
haven't invested much in using this code path properly). Thus I fear that
something like will-animate: volatile might be specific to the
implementation based on what they can optimize and what they can't. How
would a web author know to specify 'will-animate: volatile' in a way that
is portable without assuming, and ideally even knowing about, details of
the implementation.



On Wed, Nov 27, 2013 at 3:50 PM, Ali Juma <ajuma@chromium.org> wrote:

> On Wed, Nov 27, 2013 at 2:15 PM, Benoit Girard <bgirard@mozilla.com>wrote:
>
>> Excellent point. My proposal started initially with the values 'auto |
>> yes' but was later changed.
>>
>> Currently all major web browser use buffered rendering (layering system)
>> and I suspect most implementations of will-animate will be at least
>> initially be a hint to these buffering/layering decision. If a
>> buffering/layering system knows that a page will-animate, scrolling can
>> hint to the page that it should buffer outside the visible bounds
>> (overflow). It is useful to distinguish between scrolling and say opacity
>> where buffering outside the bounds is not useful. Similarly, I think
>> hinting what will animate is more implementation agnostics. For example on
>> mobile there might a highly power efficient fixed function
>> 'bliting/blending' hardware that may be usable to animate scrolling and
>> opacity but not 3d transform. Although gecko has no such plans, some
>> implementations may choose to optimize certain animations by caching a non
>> raster buffer such as a display list or a vector representation.
>>
>
> That's a great point. Along similar lines, how about also allowing a hint
> that an element will animate but that its content is going to change every
> frame (something like "will-animate: volatile")? This would allow
> distinguishing between translations (where it's useful for an
> implementation to both layerize as well as cache the content of the element
> being animated), and deformations (e.g. [1], [2]) where it's useful to
> layerize (so that content behind the animation is cached) but actually
> wasteful to cache the content being animated. With a "will-animate:
> volatile" hint, an implementation might choose to simply rasterize the
> frequently-changing content on the GPU every frame (see [3] for some more
> context).
>
> [1] http://jsfiddle.net/humper/yEX8u/3/
> [2] http://jsfiddle.net/vBQHH/3/
> [3]
> https://docs.google.com/a/chromium.org/document/d/1Vi1WNJmAneu1IrVygX7Zd1fV7S_2wzWuGTcgGmZVRyE/edit?pli=1#
>
>