Last Comment Bug 875219 - (web-animations) Implement Web Animations
(web-animations)
: Implement Web Animations
Status: NEW
: dev-doc-needed, feature, meta
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: All All
: -- normal with 22 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 888862 998245 1178660 1216843 1216844 1267510 1273784 767924 767926 880596 883493 903277 928953 1033114 1067769 1096773 1151731 1183521 1211783 1212720 1217252 1217256 1226047 1244586
Blocks: 985861
  Show dependency treegraph
 
Reported: 2013-05-23 00:04 PDT by Daniel Holbert [:dholbert]
Modified: 2016-05-18 00:34 PDT (History)
55 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Compile error log (1.20 KB, text/plain)
2013-09-02 21:26 PDT, Shelly Lin [:shelly]
no flags Details

Description Daniel Holbert [:dholbert] 2013-05-23 00:04:23 PDT
Filing this as a tracking bug to implement web animations:
  https://wiki.mozilla.org/Platform/Layout/Web_Animations
Comment 1 Daniel Holbert [:dholbert] 2013-05-23 00:09:07 PDT
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] 2013-05-23 00:15:29 PDT
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] 2013-06-27 19:59:45 PDT
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) 2013-07-30 00:00:19 PDT
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) 2013-08-08 22:42:18 PDT
Adding dependencies for WebIDL work that needs to be done.
Comment 6 Shelly Lin [:shelly] 2013-09-02 21:22:29 PDT
(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] 2013-09-02 21:26:34 PDT
Created attachment 798692 [details]
Compile error log
Comment 8 David Zbarsky (:dzbarsky) 2013-09-03 13:49:52 PDT
(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) 2013-10-21 05:37:43 PDT
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] 2013-10-22 01:38:04 PDT
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] 2013-10-22 01:54:14 PDT
Why do we have to invent yet another animation spec?
http://xkcd.com/927/
Comment 12 Daniel Holbert [:dholbert] 2013-10-22 02:24:21 PDT
(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] 2013-10-22 02:34:49 PDT
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] 2013-10-23 01:49:38 PDT
(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) 2014-03-04 22:07:00 PST
I've updated all the patches I had and pushed them to https://github.com/dzbarsky/gecko-dev/tree/web-anim

Note You need to log in before you can comment on or make changes to this bug.