The Firefox fired excessive animationiteration event.
But We fixed specification in order to prevent firing the animationiteration when animation is start.
For detail, See https://github.com/w3c/csswg-drafts/issues/68
MozReview-Commit-ID: 391DRxSpq86
--HG--
extra : rebase_source : 38e6710da4d9ad7422d6313eeae2803402a51b24
I confirmed that animate-preserve3d-child.html still fails without the
original patch in the bug.
--HG--
extra : transplant_source : %2Bqq%E3%28f%BC%CF%E0%02%205.%14V%ABX%F1%87%1B
frame->Preserves3D() is whether the frame's parent has transform-style:
preserve-3d, which means that the frame is part of the same 3-D scene as
its parent. frame->Preserves3DChildren() is whether the frame itself
has transform-style: preserve-3d, which means that the frame is part of
the same 3-D scene as its children.
Neither of these are valid cases for doing off-main-thread (OMT)
animation because all of the layers in a preserve-3d scene are currently
siblings of each other, rather than preserving ancestor/descendant
relationships. This means that it's not valid to animate transform of
the parent on the compositor because the compositor animation won't
update any of its children that have layers. Likewise, it's not valid
to animate transform of the child on the compositor because the code
that sends transform information to the compositor doesn't handle the
accumulation of transforms needed to get the "right" transform for the
child (i.e., with the transforms of its ancestors up to the top of the
3-D scene merged in).
This means that we do OMT animation for slightly fewer cases with the
patch than we did without the patch. This means it's pretty low risk in
terms of correctness, although there's a chance it might regress
performance on one of the (somewhat limited) set of cases where the
optimization was valid. (Bug 779598 covers doing OMT animation for
preserve-3d cases, and depends on the work ongoing in bug 1097464.)
The animate-preserve3d-parent.html reftest doesn't fail without the
patch, since something seems to invalidate in the test; it was testing
the testcase that showed correct behavior when the mouse was moving, so
this isn't incredibly surprising (although that invalidation from mouse
movement is itself worth debugging). The animate-preserve3d-child.html
test does fail without the patch, though.
(With an initial transform of none instead of the 30deg transform, both
tests also show an invalidation bug without the patch.)
