| Issue 46789: | Accelerated Compositing: Artifacts/blink when enabling a transform | |
| 3 people starred this issue and may be notified of changes. | Back to list |
Restricted
Sign in to add a comment
|
Chrome Version : 6.0.440.0 (Developer Build 50076) URLs (if applicable) : http://peter.sh/2010/06/chromium-now-features-gpu-acceleration-and-css-3d-transforms/ 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. http://peter.sh/files/chrome-ac-scrollbar.jpg
Aug 12, 2010
#1
peter%lvp-media.com@gtempaccount.com
Aug 12, 2010
11:03 < Peter`> Would anyone mind cc'ing nduca@chromium.org to https://code.google.com/p/chromium/issues/detail?id=46789 ? He seems to be working on it
Cc:
nd...@chromium.org
Labels: -Area-Undefined Area-WebKit Feature-GPU
Aug 12, 2010
Hmmm, interesting. Will take a look at this when I've finished my current paint bug. :)
Status:
Assigned
Owner: nd...@chromium.org
Aug 16, 2010
(No comment was entered for this change.)
Labels:
Mstone-7
Aug 17, 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.
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.
Aug 18, 2010
Filed webkit bug: https://bugs.webkit.org/show_bug.cgi?id=44196
Aug 18, 2010
(No comment was entered for this change.)
Status:
Started
Aug 22, 2010
(No comment was entered for this change.)
Labels:
Feature-GPU-compositing
Oct 14, 2010
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
Status:
Verified
Oct 12, 2012
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.
Labels:
Restrict-AddIssueComment-Commit
Mar 10, 2013
(No comment was entered for this change.)
Labels:
-Area-WebKit -Feature-GPU -Mstone-7 -Feature-GPU-compositing Cr-Content Cr-Internals-GPU Cr-Internals-GPU-Compositing M-7
Mar 13, 2013
(No comment was entered for this change.)
Labels:
-Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Apr 5, 2013
(No comment was entered for this change.)
Labels:
-Cr-Internals-GPU-Compositing Cr-Internals-Compositing
Apr 5, 2013
(No comment was entered for this change.)
Labels:
-Cr-Content Cr-Blink
|
||||||||||
| ► Sign in to add a comment | |||||||||||
