875219 - (web-animations) [meta] Implement Web Animations

Status: RESOLVED FIXED

(Core :: General, enhancement)

Description

[Daniel Holbert [:dholbert]]

Filing this as a tracking bug to implement web animations:
  https://wiki.mozilla.org/Platform/Layout/Web_Animations

Comment 1

[Daniel Holbert [:dholbert]]

Some first steps for this (probably to be done in helper bugs, possibly in parallel) would be:

 - Create WebIDL files, etc. to expose the relevant JS APIs.

 - Tweak the existing CSS Animations / Transitions infrastructure (nsAnimationManager, nsTransitionManager) to be expressed in terms of Web Animations constructs.  (So: evolution of those existing classes into something web-animations-flavored)

 - (other things?)

Comment 2

[Daniel Holbert [:dholbert]]

Relevant high-level classes:
* nsSMILAnimationController (per-document, has a list of all SVG Animations):
  http://mxr.mozilla.org/mozilla-central/source/content/smil/nsSMILAnimationController.h

* nsAnimationManager & nsTransitionManager (per-presshell, manages a list of elements with transitions/animations and (per-animated-element) info about animated properties):
  http://mxr.mozilla.org/mozilla-central/source/layout/style/nsAnimationManager.h
  http://mxr.mozilla.org/mozilla-central/source/layout/style/nsTransitionManager.h

* nsStyleAnimation (poorly named; basically, just utility class for interpolation code):
  http://mxr.mozilla.org/mozilla-central/source/layout/style/nsStyleAnimation.h

Comment 3

[Nick Cameron [:nrc]]

OK, apologies for taking so long to get to this. I promised to add some thoughts about how to best go about implementing the model part of web animations (the idea being that doing that would expose any problems before we got to web-facing API).

There are basically three kinds of animation to merge, I suggest merging first CSS animations and transitions, and then adding SMIL to the mix, because the first two already share a bunch of code (AnimationCommon.h/.cpp), but could probably share more. I don't know much about SMIL but it is very different code so, unifying that with transitions and animations will be harder.

For the animations/transitions, currently we share some code but treat them differently in layout. For off-main thread animations (OMTA, currently only used on b2g, but we're working on other platforms) we treat them identically in gfx (we convert transitions into animations). (For main thread animations (the more common way) gfx doesn't really know about animation things at all). Note that we can only a small subset of things off main thread.

In implementation terms, there are two 'parts' to our current model - there is the representation of the animations and the logic for starting, stopping, etc. Bug 880596 deals with using one representation for both animations and transitions (I'll add a comment there about that). I think, but am not sure, that we will need to keep the start/stop logic separate. How to do that might be a little challenging.

From a high level, I envisage having an early step (probably where we currently construct the variation structs in ns*Manager.h) where we convert animations and transitions into web animations structs. These would then be used for main thread and OMTA. There probably won't really be an explicit translation, more that we just store in a single set of structs.

Then we need to think a bit about whether we can unify the logic parts of animation/transition. I like to think that with a bit more 'early translation' we can, but I'm not sure.

Then we fit SMIL into all of this.

Comment 4

[David Zbarsky (:dzbarsky)]

Brian, Shelly and I decided to prototype this work in a shared repo (https://github.com/dzbarsky/mozilla-central/tree/webanim)

Anyone else who is interested in working on this, feel free to ping me and I will add you as a collaborator.

Comment 5

[David Zbarsky (:dzbarsky)]

Adding dependencies for WebIDL work that needs to be done.

Comment 6

[Shelly Lin [:shelly]]

(In reply to David Zbarsky (:dzbarsky) from comment #4)
> Brian, Shelly and I decided to prototype this work in a shared repo
> (https://github.com/dzbarsky/mozilla-central/tree/webanim)
> 
> Anyone else who is interested in working on this, feel free to ping me and I
> will add you as a collaborator.

Hey David, I tried building the mc with your repo and it failed at 

ParGroup.h:40:78: error: no matching function for call to ‘mozilla::dom::ParGroup::ParGroup(JSObject*, const mozilla::dom::Nullable<mozilla::dom::Sequence<mozilla::dom::OwningNonNull<mozilla::dom::TimedItem> > >&, const mozilla::dom::TimingInput&)’

(Please find more details from the attachment)

Any idea of what I did wrong? Thanks!

Comment 7

[Shelly Lin [:shelly]]

Attachment: Compile error log

Comment 8

[David Zbarsky (:dzbarsky)]

(In reply to Shelly Lin [:shelly] from comment #6)
> (In reply to David Zbarsky (:dzbarsky) from comment #4)
> > Brian, Shelly and I decided to prototype this work in a shared repo
> > (https://github.com/dzbarsky/mozilla-central/tree/webanim)
> > 
> > Anyone else who is interested in working on this, feel free to ping me and I
> > will add you as a collaborator.
> 
> Hey David, I tried building the mc with your repo and it failed at 
> 
> ParGroup.h:40:78: error: no matching function for call to
> ‘mozilla::dom::ParGroup::ParGroup(JSObject*, const
> mozilla::dom::Nullable<mozilla::dom::Sequence<mozilla::dom::
> OwningNonNull<mozilla::dom::TimedItem> > >&, const
> mozilla::dom::TimingInput&)’
> 
> (Please find more details from the attachment)
> 
> Any idea of what I did wrong? Thanks!

Sorry about that!  Looks like the rebase was clean but other parts of the code changed, causing some bitrot here.  I pushed a fix for that and another compilation failure.

Comment 9

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Today we discussed the implementation strategy for this and decided we should make small incremental steps that we can use immediately rather than having a big-bang switch-over.

The first steps we have in mind are:
* Make a common animation object that is based on Web Animations' Animation interface but with only the members needed to support CSS Animations
* Make CSS Animations use this new animation object
* Make CSS Transitions use this new animation object
* Create a pref for exposing the API (initially pref'ed off)
* Expose a subset of the Animation interface when the pref is switched on

Comment 10

[Shelly Lin [:shelly]]

I'll take the first job "Making a common animation object" if no one has objection for it. I think bug 880596 would be the one (should probably change the bug title to match up with the goal though).

Comment 11

[Masatoshi Kimura [:emk]]

Why do we have to invent yet another animation spec?
http://xkcd.com/927/

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Masatoshi Kimura [:emk] from comment #11)
> Why do we have to invent yet another animation spec?

Let's not get into too much of a back-and-forth over that here. Bugs are notoriously bad places for non-"how do we implement this" type discussion.

But briefly, the "one universal standard" idea that's mocked in that XKCD cartoon is more compelling in this case, since
 (a) there are only three standards that we're trying to unify (which cover distinctly different use cases, but with similar unifyable functionality)
 (b) we intend to rewrite the other standards in terms of this new standard
 (c) we intend to reimplement our implementations of the other standards in terms of this new standard

Comment 13

[Daniel Holbert [:dholbert]]

so the end state hopefully won't be "There are 4 competing standards [where previously there were 3]".

Instead, we're shooting for "There's one common foundational standard, with three higher-level abstractions specified and implemented in terms of that one standard, such that they play nicely together in well-defined ways. [where previously they were specced independently and didn't play well together in any sort of defined way]"

Comment 14

[Shelly Lin [:shelly]]

(In reply to Shelly Lin [:shelly] from comment #10)
> I'll take the first job "Making a common animation object" if no one has
> objection for it. I think bug 880596 would be the one (should probably
> change the bug title to match up with the goal though).
Correction, I meant to take the second one, "Make CSS Animations use this new animation object".

Comment 15

[David Zbarsky (:dzbarsky)]

I've updated all the patches I had and pushed them to https://github.com/dzbarsky/gecko-dev/tree/web-anim

Comment 16

[MarjaE]

Animation can hurt, can make it hard to see, can trigger migraines, and can trigger seizures. Adding a11y review because it's important for users to be able to stop Firefox implementing animation.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Closing since we've already implemented a bunch of the Web Animation APIs. We will open new bugs for rest of works such as shipping composite or some such.

Comment 18

[Florian Scholz (Open Web Docs)]

Marking also as dev-doc-complete given there is a lot of material at https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API.
Please add dev-doc-needed to any new Web Animation API features, though.