Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Making some changes to transitions starting and animations/transitions interaction
37 views
Skip to first unread message
L. David Baron
Mar 18, 2013, 7:07:59 PM3/18/13
to dev-tec...@lists.mozilla.org
I just sent a proposal to www-style about having css3-transitions
describe a clearer model for how transitions and animations interact
and how transitions are started:
http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html
This would hopefully clear up a bunch of areas where there's
significant lack of interoperability between implementations of
transitions and animations, and where the spec is very unclear.
I wanted to write a bit more here about how I see this being
implemented in Gecko. I think the big pieces would be:
(1) Removing the concepts of "style with animation" and "style
without animation" that we have, which I think has proven not to
meet the goals I originally intended them to meet (providing sane
behavior for requirements (3) and (5) in the above message). This
would be replaced with what I propose in item (A) in that message,
which is essentially the miniflush concept that we have implemented
for suppressing the main thread style updates for animations that
are running on the compositor, but which we don't currently use
beyond that code. I think this removal will end up being a pretty
substantial code simplification, and the performance cost of the
miniflush will be roughly the same as the performance cost of the
current dual-style setup.
(2) Changing how animations and transitions work in the cascade.
Note that currently compositor-driven animations have different
cascading behavior than animations not running on the compositor,
which is a relatively serious bug (847287). I admit I don't have a
completely concrete idea about how to do this, but I think it's not
going to be all that hard; at a concrete level it might come down
to having nsIStyleRules in the cascade at two different places
(both at the top of the cascade and at the official location) in
order to let the rule safely record which properties the animation
or transition is the winning rule for, and then recording that
information so that we can use it for the compositor-driven
animations. I don't think this is too hard, though; I just haven't
implemented it yet.
I wanted to call this out both because it implies some somewhat
significant changes coming in code that we're depending on pretty
heavily, and to encourage others to comment either here about the
Gecko-specific parts or on www-style about the standard bits.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂
describe a clearer model for how transitions and animations interact
and how transitions are started:
http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html
This would hopefully clear up a bunch of areas where there's
significant lack of interoperability between implementations of
transitions and animations, and where the spec is very unclear.
I wanted to write a bit more here about how I see this being
implemented in Gecko. I think the big pieces would be:
(1) Removing the concepts of "style with animation" and "style
without animation" that we have, which I think has proven not to
meet the goals I originally intended them to meet (providing sane
behavior for requirements (3) and (5) in the above message). This
would be replaced with what I propose in item (A) in that message,
which is essentially the miniflush concept that we have implemented
for suppressing the main thread style updates for animations that
are running on the compositor, but which we don't currently use
beyond that code. I think this removal will end up being a pretty
substantial code simplification, and the performance cost of the
miniflush will be roughly the same as the performance cost of the
current dual-style setup.
(2) Changing how animations and transitions work in the cascade.
Note that currently compositor-driven animations have different
cascading behavior than animations not running on the compositor,
which is a relatively serious bug (847287). I admit I don't have a
completely concrete idea about how to do this, but I think it's not
going to be all that hard; at a concrete level it might come down
to having nsIStyleRules in the cascade at two different places
(both at the top of the cascade and at the official location) in
order to let the rule safely record which properties the animation
or transition is the winning rule for, and then recording that
information so that we can use it for the compositor-driven
animations. I don't think this is too hard, though; I just haven't
implemented it yet.
I wanted to call this out both because it implies some somewhat
significant changes coming in code that we're depending on pretty
heavily, and to encourage others to comment either here about the
Gecko-specific parts or on www-style about the standard bits.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂
Boris Zbarsky
Mar 18, 2013, 10:27:36 PM3/18/13
to
On 3/18/13 7:07 PM, L. David Baron wrote:
> This would be replaced with what I propose in item (A) in that message,
> which is essentially the miniflush concept
At first glance this seems reasonable. Especially if we can continue to
> This would be replaced with what I propose in item (A) in that message,
> which is essentially the miniflush concept
avoid having to do any extra work here if there are no transitions
around. Can we?
-Boris
L. David Baron
Mar 18, 2013, 10:53:02 PM3/18/13
to dev-tec...@lists.mozilla.org, Boris Zbarsky
other than having a boolean saying whether any nodes have
'transition-duration' or 'transition-delay' on them. That said, we
might be able to scope this to subtrees by having a bit on style
contexts saying whether a style context or any of its descendants
has one of those properties set.
0 new messages