Re: Proposal: will-animate property

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 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. 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.

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.


>
> 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. By hinting
exactly what will change authors are less likely to misuse the property.


> 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.