W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: Proposal: will-animate property

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 2 Dec 2013 02:56:53 -0800
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: "L. David Baron" <dbaron@dbaron.org>, Benoit Girard <bgirard@mozilla.com>, Ali Juma <ajuma@chromium.org>, Matt Woodrow <matt@mozilla.com>, Cameron McCormack <cmccormack@mozilla.com>, www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
Message-ID: <FEF033BA-1312-422A-9C2F-FC8E1A991E8E@adobe.com>

I am skeptical about introducing a property used as a hint for rendering performance.

Cameron mentioned that SVG 1.2 Tiny introduced the ‘buffered-rendering’ property. At the time of writing this specification, the property seemed to be a good idea. As implementations evolved, the hint could not provide any additional value to implementations like WebKit and Gecko.

I understand the difficulties that animations and especially animated transforms have (implementation wise). I am not so convinced that the problems we have today are the problems that we have tomorrow. In 2 or 3 years we might not even use buffers for hardware accelerated transformations. Or more likely, the heuristics get much better over time because we for sure did not reach any limit today. As long as the property is a hint, it might not be a huge problem and is just one more of the deprecated and unused properties. As soon as we speak about creating a stacking context - so change of actual behavior - it could suddenly turn into a burden for the future.

Beside that, it is unclear if authors are using the property correctly. My assumption is that quite often authors will use the property because they are told to use it. This can cause problems similar to the use of translateZ(0) today. Authors use translateZ(0) to HW accelerate their content. Sadly quite often the content is to huge for buffering it on the GPU which can cause massive slowdowns and (sometimes) even crashes of the browser.

Last but not least, implementations have different compositors with different needs. It seems unclear if all implementations can benefit the same way in all situations. It could very well be that some implementations benefit differently which causes a higher diversity on performance across implementations. It could even happen that a performance boost by the hint on one implementation could cause the opposite effect on another platform.

On Nov 30, 2013, at 2:23 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Sat, Nov 30, 2013 at 1:05 PM, L. David Baron <dbaron@dbaron.org> wrote:
> I'm a little worried that there might be overlap between the CSS
> property names and the non-CSS-property-name values ('scroll' or
> 'scrolling').  That could be avoided by adding a functional syntax
> around the CSS property names, but that might be overengineering.
> Yes, I think so.
> We could call the scroll value "scroll-position". If we ever add a "scroll-position" CSS property that doesn't set the actual scroll position, we deserve what we get.
> Rob
> -- 
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w  
Received on Monday, 2 December 2013 10:59:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC