The default bug view has changed. See this FAQ.

Allow compositor-drive animation of visibility

RESOLVED FIXED in mozilla17

Status

()

Core
Layout
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: dzbarsky, Assigned: dzbarsky)

Tracking

unspecified
mozilla17
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Visibility does not actually affect the animation, since the element is always visible except for possibly the start and end states.  When the element is hidden, that is handled by layout.  This allows transitions like http://beta.timc.idv.tw/test2.html to be async.
(Assignee)

Comment 1

5 years ago
Created attachment 648934 [details] [diff] [review]
Patch
Attachment #648934 - Flags: review?(matt.woodrow)
Attachment #648934 - Flags: review?(matt.woodrow) → review+
Backed out as part of the mass tree revert due to bustage caused by other landings:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c801b99d726f

Once the tree is open again, this can reland :-)
(Assignee)

Comment 3

5 years ago
Relanded: https://hg.mozilla.org/integration/mozilla-inbound/rev/3f0298834ad9
https://hg.mozilla.org/mozilla-central/rev/3f0298834ad9
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
What if it's a CSS animation involving keyframes, and the visibility state needs to change somewhere in the middle due to what's specified in the keyframes (or due to repetition from animation-iteration-count)?
(Assignee)

Comment 6

5 years ago
Are you talking about something like http://pastebin.mozilla.org/1740884?
That doesn't work in Firefox currently.  In my testing, I could only get visibility to work for transitions, never for animations.

However, in theory since the animation is also sampled by the main thread, layout will set the frame invisible if it needs to, which will rebuild the layer tree.
(Assignee)

Comment 7

5 years ago
So when I fix the 30%% thing, it does actually work as expected, even with async animations, because of what I said in my previous comment.
Maybe that's because we're not doing anything to suppress the animation running normally in addition to running on the compositor thread?  But once we do, won't it be a problem?
(Assignee)

Comment 9

5 years ago
That is correct.  At that point we can just sample the visibility on the compositor and set a scale(0,0) transform matrix on the layer if it should be invisible.  Or do you think we should do that now?
Depends on: 782845
No longer depends on: 782845
This was backed out in bug 784239 (which is good, I think).
You need to log in before you can comment on or make changes to this bug.