Bug 875219 (web-animations)

Implement Web Animations

NEW
Unassigned

Status

()

Core
General
4 years ago
6 months ago

People

(Reporter: dholbert, Unassigned)

Tracking

(Depends on: 1 bug, {dev-doc-needed, feature, meta})

Trunk
dev-doc-needed, feature, meta
Points:
---
Dependency tree / graph
Bug Flags:
a11y-review ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Filing this as a tracking bug to implement web animations:
  https://wiki.mozilla.org/Platform/Layout/Web_Animations
(Reporter)

Comment 1

4 years ago
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?)
(Reporter)

Comment 2

4 years ago
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
Depends on: 880596

Comment 3

4 years ago
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.

Updated

4 years ago
Depends on: 888862
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.
Adding dependencies for WebIDL work that needs to be done.
Depends on: 883493, 767924, 903277, 767926

Comment 6

4 years ago
(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

4 years ago
Created attachment 798692 [details]
Compile error log
(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.
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
Depends on: 928953
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).
Why do we have to invent yet another animation spec?
http://xkcd.com/927/
(Reporter)

Comment 12

4 years ago
(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
(Reporter)

Comment 13

4 years ago
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]"
(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".
I've updated all the patches I had and pushed them to https://github.com/dzbarsky/gecko-dev/tree/web-anim
See Also: → bug 985861
Depends on: 998245
Keywords: dev-doc-needed
Depends on: 1033114
Depends on: 1049975
Depends on: 1067769
Blocks: 985861
Depends on: 1096773
Depends on: 1151731

Updated

2 years ago
See Also: → bug 1165216
Depends on: 1178660
No longer depends on: 1049975
No longer depends on: 1067769
Depends on: 1067769
Depends on: 1183521
Depends on: 1212720
Depends on: 1217252
Depends on: 1217256
Depends on: 1226047
Depends on: 1216844
Depends on: 1216843
Depends on: 1211783

Updated

2 years ago
Depends on: 1244586

Updated

2 years ago
Depends on: 1246320
No longer depends on: 1246320
Keywords: feature, meta
Depends on: 1267510
Depends on: 1273784
Depends on: 1283387
Depends on: 1291468

Updated

11 months ago
Depends on: 1302038

Updated

9 months ago
Depends on: 1314537

Updated

9 months ago
Depends on: 1317914

Comment 16

6 months ago
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.
Flags: a11y-review+

Updated

6 months ago
Flags: a11y-review+ → a11y-review?
You need to log in before you can comment on or make changes to this bug.