[Webkit-unassigned] [Bug 98177] Needless repaints at the beginning and end of a transition of a translate3d.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=98177





--- Comment #8 from John Barr <johnbarr at google.com>  2012-11-23 07:19:32 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.