W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css3-animations] Establishing stacking context at animation start

From: Brian Birtles <bbirtles@mozilla.com>
Date: Wed, 27 Apr 2016 13:49:01 +0900
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Simon Fraser <smfr@me.com>
Cc: "www-style@w3.org list" <www-style@w3.org>
Message-ID: <572044BD.7020403@mozilla.com>
On 2015/09/29 8:27, Tab Atkins Jr. wrote:
> On Sun, Sep 27, 2015 at 11:59 AM, Simon Fraser <smfr@me.com> wrote:
>> Consider the following example:
>> @keyframes move {
>> from, 49% { transform: none;}
>> 50% { transform: translateX(10px); }
>> to { transform: translateX(100px); }
>> }
>> <div style=“animation: move 10s”></div>
>> When should the div become a CSS stacking context? At the start of the animation, or at the 49% keyframe?
>> User agents generally agree on the latter[1], but I think it might make more sense to create stacking context at the start of the animation, if any of the animating property values create stacking context. This allows user agents to avoid having to recompute stacking in the middle of an animation in some cases.
>> It’s temping to borrow spec language from will-change for this, but we again run into the question of whether keyframes that contain property values that are no-ops on the target element affect stacking (e.g. transforms on <span>).
> I'm inclined to say that we just apply the property values literally -
> you get a stacking context between 49% and 100% only.  If you want a
> stacking context the whole time, set `will-change` appropriately.

I've just come across this because we're trying to fix some flicker when 
doing frame-based animations with CSS animations using animation-delay.[1]

In short, we'd like to be able to create a stacking context during the 
delay phase so that when the animation's scheduled time to run arrives, 
it's ready to go. We can even have it present on the compositor so that 
the cartoon runs uninterrupted. (In fact, we only encounter flicker when 
we try to run these sort of animations on the compositor because when we 
hit the start of each delayed frame we have to establish the new 
stacking context on the main thread, render layers there, then upload to 
the compositor and often we don't make it within our frame budget.)

I've noticed that IE and Edge appear to do this already.[2] Their 
behavior also differs in the test case Simon provided.[3]

Since IE and Edge already do this, WebKit seems interested, and it would 
seem to provide performance advantages, any chance we could revisit this?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1223658
[2] https://bug1223658.bmoattachments.org/attachment.cgi?id=8745192
[3] http://codepen.io/anon/pen/gaLXYW
Received on Wednesday, 27 April 2016 04:49:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC