Re: Proposal: will-animate property

On Wed, Nov 27, 2013 at 4:38 PM, Benoit Girard <bgirard@mozilla.com> wrote:

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

You're right that this particular example could be handled in a
non-re-rasterizing way. That's because the underlying image is static. But
consider elements that are truly being invalidated every frame, where
there's nothing static that can be re-used. In this situation, a web author
could safely use "will-animate: volatile", and all implementations would
benefit by being able to save the memory cost of caching the content.
Perhaps "will-animate: dynamic" better conveys the intent than "volatile":
the element has content that's being dynamically generated every frame.