- From: Ali Juma <ajuma@chromium.org>
- Date: Wed, 27 Nov 2013 15:50:52 -0500
- To: Benoit Girard <bgirard@mozilla.com>
- Cc: Cameron McCormack <cmccormack@mozilla.com>, www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Message-ID: <CANLC6v1aCh7xONZ1CUBQ6Kt9m6TjLCeJMGu_BnXwWzSaXR2O8g@mail.gmail.com>
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