Bug 98177 – Needless repaints at the beginning and end of a transition of a translate3d.

• Status: UNCONFIRMED
• Component: Layout and Rendering

[John Barr]

Created attachment 166716 [details]
composite layer demo

Chrome Version       : 24.0.1272.0 canary
OS Version: OS X 10.8.1
URLs (if applicable) : See attachment.
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari Version 6.0 (8536.25): FAIL (observed through "Timelines" -> "Layout & Rendering", extra repaints)
     Chrome 21.0.1180.89: FAIL

What steps will reproduce the problem?
1. Enable "Composited render layer borders" in chrome://flags
2. Load attached file. In this file there is an element with a translate3d with a 1sec transition. The translate3d is changed every two seconds.
3. Observation 1 - first red box: Note that during the transition of the element with translate3d the "opacity" element is turned into a composite layer. This composite layer goes away after the transition is over.
4. Observation 2 - second red box: This time the element with opacity is contained within another composite layer (forced with an identity translate3d). In this case the "opacity" element is not made into its own composite layer during the transition.
5. ...

What is the expected result?
5. Observation 3 - third red box: Element with opacity should not be made into its own composite layer for the same reason the element with opacity in Observation 2 is not made into its own composite layer.


What happens instead?
5. Observation 3 - third red box: Element with opacity is made into its own composite layer. The only difference here is that the element with opacity has a sibling with is a composite layer.

The above is an example were we needlessly make elements with opacity their own composite layer for the duration of the transition of a translate3d. Promoting these elements to be their own composite layer and back causes repaints which are wasteful. Fixing this bug would improve performance.

Note this not only affects elements with opacity, but also elements with position: relative/absolute in the same way.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1

[Simon Fraser (smfr)]

This is because we turn off overlap testing when there's a transform animation running.

[Adrienne Walker]

(In reply to comment #1)
> This is because we turn off overlap testing when there's a transform animation running.

Yes, that explains "Observation 1", since we don't want the animation to jank when the first "opacity" layer overlaps it.

However, that doesn't explain "Observation 3".  Since the third "opacity" element already has a composited parent, there's no need to promote it.  Once something becomes a composited layer, it seems like we should turn back on overlap testing.

[Simon Fraser (smfr)]

(In reply to comment #2)
> (In reply to comment #1)
> > This is because we turn off overlap testing when there's a transform animation running.
> 
> Yes, that explains "Observation 1", since we don't want the animation to jank when the first "opacity" layer overlaps it.
> 
> However, that doesn't explain "Observation 3".  Since the third "opacity" element already has a composited parent, there's no need to promote it.  Once something becomes a composited layer, it seems like we should turn back on overlap testing.

I think we can only do this if the composited parent has overflow: hidden. Bug 90633 covers that.

[Adrienne Walker]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > This is because we turn off overlap testing when there's a transform animation running.
> > 
> > Yes, that explains "Observation 1", since we don't want the animation to jank when the first "opacity" layer overlaps it.
> > 
> > However, that doesn't explain "Observation 3".  Since the third "opacity" element already has a composited parent, there's no need to promote it.  Once something becomes a composited layer, it seems like we should turn back on overlap testing.
> 
> I think we can only do this if the composited parent has overflow: hidden. Bug 90633 covers that.

I don't understand why overflow:hidden / clipping comes into play here.  If you have some tree like this:

    -A (animated)
    -B (sibling of A, has backing)
     -C (child of B)

...then there is no way that C could overlap A's composited layer bounds but not B's composited layer bounds.  Therefore, it should always be correct to draw C into B's backing, regardless of the position of A.

[Simon Fraser (smfr)]

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > This is because we turn off overlap testing when there's a transform animation running.
> > > 
> > > Yes, that explains "Observation 1", since we don't want the animation to jank when the first "opacity" layer overlaps it.
> > > 
> > > However, that doesn't explain "Observation 3".  Since the third "opacity" element already has a composited parent, there's no need to promote it.  Once something becomes a composited layer, it seems like we should turn back on overlap testing.
> > 
> > I think we can only do this if the composited parent has overflow: hidden. Bug 90633 covers that.
> 
> I don't understand why overflow:hidden / clipping comes into play here.  If you have some tree like this:
> 
>     -A (animated)
>     -B (sibling of A, has backing)
>      -C (child of B)
> 
> ...then there is no way that C could overlap A's composited layer bounds but not B's composited layer bounds.  Therefore, it should always be correct to draw C into B's backing, regardless of the position of A.

I think you are right.

[John Barr]

This bug is particularly important to the Safari browser. This bug, in combination with Safari's not synchronizing compositing layer updates, causes elements to flash. This occurs at the beginning and end of transitions of transforms, when unrelated elements on the page with either opacity or display flash due to being promoted to compositing layers and back.

[Simon Fraser (smfr)]

(In reply to comment #6)
> This bug is particularly important to the Safari browser. This bug, in combination with Safari's not synchronizing compositing layer updates

What do you mean by that?

[John Barr]

Lets say element A has a short (200ms) -webkit-transition of its -webkit-transform property.

Unrelated elements B, C, D with opacity or position: relative on them are promoted to their own compositing layer for the duration of this transition due to this bug.

Since in Safari the compositor does not wait for the changes to different compositing layers to complete before rendering the next frame, the user can one compositing layer change before another. (This also affects different tiles in the same compositing layer.)

When the transition begins the layers that B, C, D used to be in are repainted to remove B, C, D. Then B, C, D are rendered into their own layer. Due to the above mentioned limitations of the safari compositor, one or more frames may be seen without B, C, D so these elements appear to flash.

When the transition completes, the layers which contain B, C, D now go away and B, C, D are repainted into their original layers. Again a flash.


This is a huge problem for websites as the only recourse possible for website authors is to force these elements to have compositing layers all of the time. Sprinkling identity translate3d(0,0,0)'s on many elements with opacity or position: non-static to prevent these flashes.

[Simon Fraser (smfr)]

(In reply to comment #8)

> Since in Safari the compositor does not wait for the changes to different compositing layers to complete before rendering the next frame

This is not true. We did have some flickers related to using CATiledLayer, but those were fixed via bug 99806.

If you still see issues on TOT, please open new bugs.