Re: Proposal: will-animate property

On Mon, Dec 2, 2013 at 11:56 PM, Dirk Schulze <dschulze@adobe.com> wrote:

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

'buffered-rendering' is not the right level of abstraction; it's too
strongly tied to a particular implementation detail.

That said, there are situations where we could benefit from
'buffered-rendering' or 'will-animate', and I think there always will be. I
can't think of a heuristic that will capture the case where a fresh page is
loaded, JS picks a normal-looking element from the DOM and sets its inline
opacity or transform style.
(I've thought a lot about more advanced heuristics, like examining
selectors in the page's stylesheets to see which elements could potentially
have CSS animations or transitions triggered if a class is applied, for
example. But advanced heuristics are difficult to implement and very
difficult for authors to understand. You also run into the problem of the
rendering potentially being different when an element is in a stacking
context vs when it is not.) Predicting the future behavior of programs is
an intrinsically hard problem.

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

That is true. However, properties that induce stacking contexts are
numerous and one more is a very minor burden.

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

Authors will definitely abuse 'will-animate'. We will need to provide
guidance for appropriate use of 'will-animate' and come up with anti-abuse
heuristics.

I think we'll be telling authors to minimize the number of elements to
which they apply 'will-animate' (perhaps by adding 'will-animate' shortly
before the animation starts), and to ensure those elements are not much
bigger than the viewport, and that if these constraints are violated we
will stop optimizing 'will-animate' on some of the elements, or all of the
elements, or even the entire domain.

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

That's true for a property like 'buffered-rendering' that appears to force
a particular implementation. But 'will-animate' is the right level of
abstraction to give the implementation the information it needs to make the
right decision. If the decision is "we don't need to do anything special to
handle animation of this property", that's fine.

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