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
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC