Re: Proposal: will-animate property

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#

Received on Wednesday, 27 November 2013 20:51:19 UTC