- From: Benoit Girard <bgirard@mozilla.com>
- Date: Wed, 27 Nov 2013 14:15:20 -0500
- To: Ali Juma <ajuma@chromium.org>, Cameron McCormack <cmccormack@mozilla.com>
- Cc: www-style <www-style@w3.org>
- Message-ID: <CAAyLn85spUrSoYJQC1o+ABUSvvUQat-DHnvR2fyuAucsoLEyYA@mail.gmail.com>
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. Thus the proposal was changed to not assume that implementations will always and forever use the same optimizations for all types of animations but provide more flexibility for interesting optimizations given available hardware. Ideally proposing something similar to SVG buffered-rendering would be nice but I'm afraid that it's inflexible and tied strongly with a particular implementation i.e. buffered/layer optimizations. Already the use case to optimize scrolling differently is very strong as it allows pre-rederending content.
Received on Wednesday, 27 November 2013 19:15:48 UTC