Re: [webkit-dev] Implementing Web Animations

[Darin Adler]

> On Nov 4, 2015, at 6:19 PM, Nikos Andronikos 
>  wrote:
> 
> The current plan, after chatting to Dean at TPAC, will be to implement the 
> web animations model as a new module, with a runtime flag for switching CSS 
> and SVG animations over to use the new model.

We should have a goal to have the CSS and SVG animations the same or higher 
performance when rebuilt on top of the new model. I suppose I’m mainly talking 
about the performance of setting up the animations, but CPU use and frame rate 
of the animation itself is interesting too. I think a good way to start would 
be to make our own WebKit benchmark for each of those that we can use to see 
performance changes during development and also validate our decision at the 
moment we flip the switch to the new model.

I don’t understand why the “switch CSS and SVG animations to the new model” 
would be a runtime flag. That sounds like something that should be a compile 
time thing to me.

> I’m also planning to change the SVG DOM so that animVal aliases baseVal per 
> the SVG WG resolution [2] and the SVG 2 spec [3]. This should substantially 
> clean up the SVG implementation and make future work easier.

That should allow us to remove a lot of code. And it does seem like the right 
call for the future of SVG. But what about compatibility? Has anyone done 
research on the effect this would have on websites? What about in-app content 
on platforms like iOS?

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Web Animations

[Nikos Andronikos]

On 6 Nov 2015, at 3:22 am, Darin Adler  wrote:

>> On Nov 4, 2015, at 6:19 PM, Nikos Andronikos 
>>  wrote:
>>
>> The current plan, after chatting to Dean at TPAC, will be to implement the 
>> web animations model as a new module, with a runtime flag for switching CSS 
>> and SVG animations over to use the new model.
>
> We should have a goal to have the CSS and SVG animations the same or higher 
> performance when rebuilt on top of the new model. I suppose I’m mainly 
> talking about the performance of setting up the animations, but CPU use and 
> frame rate of the animation itself is interesting too. I think a good way to 
> start would be to make our own WebKit benchmark for each of those that we can 
> use to see performance changes during development and also validate our 
> decision at the moment we flip the switch to the new model.

Totally agree. I’ll need to do some investigation into how we should benchmark 
the animation code and come up with a plan.

>
> I don’t understand why the “switch CSS and SVG animations to the new model” 
> would be a runtime flag. That sounds like something that should be a compile 
> time thing to me.

The Web Animations compile time flag allows us to maintain the status quo - 
i.e. those that choose to disable it will not be impacted in any way by the Web 
Animations WIP code.
But when Web Animations is enabled, I think the benefit of switching between 
implementations quickly will be extremely useful.
Switching compile time flags regularly is quite onerous due to the need to 
fully rebuild. Efficiently being able to compare against the old model will 
greatly improve the ability to test the new module.

Dean was talking about the potential for a developer menu option to switch 
between models. Though my understanding is that this needs to be hard coded at 
the moment, which isn’t ideal.

>
>> I’m also planning to change the SVG DOM so that animVal aliases baseVal per 
>> the SVG WG resolution [2] and the SVG 2 spec [3]. This should substantially 
>> clean up the SVG implementation and make future work easier.
>
> That should allow us to remove a lot of code. And it does seem like the right 
> call for the future of SVG. But what about compatibility? Has anyone done 
> research on the effect this would have on websites? What about in-app content 
> on platforms like iOS?


The SVG working group has done some investigation into the usage of 
animVal/baseVal and is unanimously in support of removing it, which says 
something about the perceived risk.

The conclusions of the working group were that usage is very low, because:
- The pattern of accessing through width.baseVal.value has never been popular, 
which is likely due to the verbosity and the unintuitive nature of the 
construct.
- IE already aliases animVal to baseVal (they don’t support SVG SMIL animation 
at all)
- Typically with SVG animations there’s little reason to query the animated 
value because of sync base timing, etc
- animVal doesn’t reflect CSS animations

There is usage on the web (e.g. github returns ~15,000 results), but it appears 
to be almost entirely in test suites.
Other results:
google "animVal filetype:svg” produces zero results
google "baseVal filetype:svg” only gives 4 results.
google “animVal filetype:js” produces 4 results.
google “baseVal filetype:js” produces 1220 results.

There was an action to add usage counters to Blink, but I don’t think this ever 
happened. The only counter we currently have is for the entire SVG 1 DOM, which 
is at about 0.04%.
https://www.chromestatus.com/metrics/feature/timeline/popularity/567

Because IE has never implemented SMIL and aliases animVal to baseVal, anything 
other than throw away content has had to make use of alternative methods to 
achieve cross platform compatibility.

In-app content is a potential risk, because it would likely be designed around 
one browser engine. But I would expect usage there to follow general usage 
patterns, except perhaps if animVal is being used in some framework that we 
don’t know about.
If you know anything more about this use case, or if you can do some internal 
investigation into iOS usage (and think it’s worthwhile), please let me know.

- Nikos
The information contained in this email message and any attachments may be 
confidential and may also be the subject to legal professional privilege. If 
you are not the intended recipient, any use, interference with, disclosure or 
copying of this material is unauthorised and prohibited. If you have received 
this email in error, please immediately advise the sender by return email and 
delete the information from your system.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev