status of my transition starting + miniflush refactoring and style attribute performance work

[L. David Baron]

[ I think it would be useful for us to share status of things we're
working on a little more often on this list, particularly where that
work is large, likely to conflict with work others are doing, or be
relevant to work others are doing. And since I have something to
share, I'll do so. ]

[ I also bcc:ed a few people working in related areas who may or may
not read dev-tech-layout regularly, but probably should. ]


I recently started on a large patch queue for
https://bugzilla.mozilla.org/show_bug.cgi?id=960465 (rewrite CSS
transition starting and transitions/animations interaction) which
will contain some related changes:

1. refactor the current miniflush code (code to update the animation
styles to the current refresh driver time while leaving style
data otherwise out-of-date, so that we can do correct style
comparisons when deciding whether to start CSS transitions when
we've suppressed style updates on the main thread while running
animations on the compositor) to do coalescing using a
RestyleTracker rather than their current ad-hoc tree-walking and
coalescing code (which will also, I believe, fix some correctness
bugs). This also means introducing the miniflush's ability to
replace certain special style rules without rerunning selector
matching into the RestyleTracker, which is useful in part (4).

2. redesign the way we start CSS transitions to use the model
described in the current spec, which involves replacing the code
whose goal is to avoid starting transitions as a result of
animations. The current code for doing this maintains
without-animation and with-animation styles as separate concepts
(but never stores both at the same time), so that style
computation involves a pass of computing without-animation
styles, and then a pass replacing them with with-animation
styles; this allowed starting of CSS transitions to be computed
based on styles that did not include animations. The new code
will remove this mechanism, and instead use the miniflush
mechanism, which updates currently-running animation style to the
present refresh driver time without updating other styles, so
that style comparisons used for starting CSS transitions are done
on style including animation data, but always comparing animation
data associated with the same time.

3. Change the way CSS transitions and animations interact with each
other in the CSS cascade.

4. Do a restyling performance optimization that we'd planned to do a
while ago, but then forgot about. This is covered by
https://bugzilla.mozilla.org/show_bug.cgi?id=977991 and could
land separately, but should be trivial to do on top of part (1).
This will prevent us from rerunning *any* selector matching for
style attribute changes. (We currently rerun selector matching
on the element whose style attribute changed, but not on its
descendants.)

At this point I've got part (1) and parts of part (2) written,
although not particularly well-tested. Unfortunately I don't think
I'll be able to land (1) without (2), unless I temporarily change
the nsINode flags from 32-bits to 64-bits, since (1) introduces a
new type of RestyleTracker (each of which requires two node bits)
and (2) removes an existing type, returning us to 2 types total.

It *might* be possible to land (2) and (3) separately, but they
might be too interrelated in terms of getting Web-compatible
behavior.

So I'm currently expecting that parts 1-3 will end up having to land
at the same time, though I might find a way to avoid that. I'm
hoping this will all (parts 1-4) land sometime in the Firefox 31
cycle, and hopefully early in the cycle.

At the same time, Brian Birtles is working on a bunch of other
things related to OMT (off-main-thread) animations (975261) and
testing of OMT animations (964646, 979658), so I'm hoping to build
up automated tests for the things that I'm fixing in this work as I
do the work.

I've tried to build a dependency tree of the things we need to do to
be comfortable shipping OMT animations in:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=980770&hide_resolved=0
(Yes, we're already shipping it in Firefox OS, but...)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Boris Zbarsky]

On 3/10/14 6:33 PM, L. David Baron wrote:
> Unfortunately I don't think
> I'll be able to land (1) without (2), unless I temporarily change
> the nsINode flags from 32-bits to 64-bits, since (1) introduces a
> new type of RestyleTracker (each of which requires two node bits)

We should land
https://bug981257.bugzilla.mozilla.org/attachment.cgi?id=8388060
(already reviewed and all) and free up that node bit. That will give
you two bits to work with, I believe.

-Boris