- 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>
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? Brian [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