Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Verified
Last visit > 30 days ago
Closed: Sep 2010
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Accelerated Compositing: Artifacts/blink when enabling a transform
Reported by, Jun 17 2010 Back to list
Chrome Version       : 6.0.440.0 (Developer Build 50076)
URLs (if applicable) :

Other browsers tested:
     Safari 5: OK
     Other browsers do not support 3D CSS (yet).

What steps will reproduce the problem?
1. In the "Transform this article" menu-block, change one of the sliders. 

What is the expected result?
Changing one of the values applies a transformation, which initializes the perspective/internals. This should happen smoothly, preferably invisible to the user.

What happens instead?
The screen rapidly blinks, scrollbar turns solud blue. This gets fixed (rerendered) when I mouse-over the scrollbar. A small blue border is visible at the bottom of the rendering-area as well.
This WebKit revision has fixed the blue border in the viewport itself, but the scrollbar still becomes blue when accelerated compositing gets enabled.
Comment 2 by, Aug 12 2010
Labels: -Area-Undefined Area-WebKit Feature-GPU
11:03 < Peter`> Would anyone mind cc'ing to ? He seems to be working on it

Comment 3 by, Aug 12 2010
Status: Assigned
Hmmm, interesting.  Will take a look at this when I've finished my current paint bug. :)
Comment 4 by, Aug 16 2010
Labels: Mstone-7
Comment 5 by, Aug 18 2010
Making some mental notes here...

When the compositor is activated by script, e.g. other than when the page first loads, the updateRect delivered to drawLayers only contains the area that WebCore perceives to be dirty --- in this case, the client area.

I need to decide between invalidating the full widget when the compositor enables, or put a special case in drawLayers for its first-time draw.
Comment 6 by, Aug 18 2010
When compositor activates due to a DOM change, webkit dirties only the rect affected by the change, in this case the client area but not the scroll bar. This causes the compositor to receive only the client area rather than the complete view.

Straightforward fix, I think. Crosses fingers.
Comment 7 by, Aug 18 2010
Filed webkit bug:
Comment 8 by, Aug 18 2010
Status: Started
Labels: Feature-GPU-compositing
Status: Fixed
Committed r66450: <>
Status: Verified
Verified in build: 7.0.517.36 beta
Platform: Win 7
Verified Fixed: Yes
Fix works, slider changes result in smooth transition, no issues present
Project Member Comment 12 by, Oct 12 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 13 by, Mar 10 2013
Labels: -Area-WebKit -Feature-GPU -Mstone-7 -Feature-GPU-compositing Cr-Content Cr-Internals-GPU Cr-Internals-GPU-Compositing M-7
Project Member Comment 14 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 15 by, Apr 5 2013
Labels: -Cr-Internals-GPU-Compositing Cr-Internals-Compositing
Project Member Comment 16 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment