[webkit-dev] Implementing Web Animations

[Nikos Andronikos]

On 6 Nov 2015, at 3:22 am, Darin Adler <darin at apple.com> wrote:

>> On Nov 4, 2015, at 6:19 PM, Nikos Andronikos <Nikos.Andronikos at cisra.canon.com.au> 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.