Re: Proposal: will-animate property

On Dec 2, 2013, at 7:12 PM, Benoit Girard <bgirard@mozilla.com> wrote:

>> On Mon, Dec 2, 2013 at 5:56 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Hi,
>> 
>> 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.
> 
> Why can't 'buffered-rendering' provide any additional value to Gecko if it was implemented?

I didn’t say it was implemented in Gecko. I also didn’t meant to compare ‘buffered-rendering’ and ‘will-animate’ on a functional basis. I just used the former property as an example where we tried to provide hints to implementations to perform better.

>  
> 
>> 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.
>> 
> This is the reason why the proposal deviates from 'buffered-rendering'. In my proposal I avoid suggesting that UA should implement this as buffered rendering. It appears Ali already has a use case where it wouldn't be implemented as such and might in fact avoid buffering entirely. I also suggest that this hint may be used for other optimizations such as keeping a display list or preparing to use specialized fixed function hardware that support a subset of animations.

You mentioned transforms and it seemed to be the main reason for the proposal. That is why I took implementation details (like buffering of transformed objects on GPU) as an example how heuristics or implementations *could* change over time and make the property irrelevant quickly.

> I don't think forcing a stacking context really provides an implementation burden. In fact it allows for a spec compliant way to perform all sorts of optimizations where a stacking context is required to perform.

Once you force the creation of a stacking context, the property is not hint anymore. It can be a burden if stacking contexts are not beneficial to performance anymore. In fact they can harm performance even today. Creating a stacking context can make a huge difference on the rendered result - not just since CSS Blending.

> 
> I agree that web browsers heuristics will improve. Particularly there's some simple cases that should be detected better. However any changes made via Javascript are difficult to predicts for instance. And it's been my experience that heuristics can be frustrating to authors because the performance is unpredictable and heuristics are often a black box and difficult to trigger properly.

That is an absolutely valid concern.

>  
> 
>> 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.
> 
> Crashes from using translateZ is entirely a poor implementation and should be reported as a bug. Since translateZ is already being used today to hint animations it is something that is already wanted. translateZ is a poor hint because it will force code paths for 3D transforms that may be entirely different then the code paths we want to hit for efficient scrolling or opacity such as using fixed function hardware.

I don’t disagree that a crash is a bug that should be fixed :)

> By hinting exactly what will change authors are less likely to misuse the property.

It is very well possible to misuse such a property and make user addict to a special behavior on the browser that may speed up their performance today but end up to be a bottle neck on improvements later.

> 
> 
>> 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.
> 
> I think this is actually a strength to this proposal. Using translateZ to hint will-animate opacity will cause sub optimal optimizations with a non hardware accelerated software compositor. By declaring the intends a UA can make decisions that take into consideration the hardware available on the device (fixed function hardware, integrated gpu, discrete gpu) and take into account the memory limitations of the device. It can prioritize the limited memory capacity and bandwidth and focus on optimizing animations that are costly for that device. If the will-animate hint will lead to a performance regression the UA should ignore it.

That introduces a whole new type of heuristics that need to be developed and require authors to understand specifics of the implementation in the mean time. It looks a bit like you change the way to look at it. Without the property you need heuristics how you can improve the performance, with the property you ned heuristics when you ignore the property. Again, with the creation of stacking contexts, the property is no hint anymore but changes the behavior actively.

Greetings,
Dirk

Received on Monday, 2 December 2013 20:15:44 UTC