Bug 140177 - Artifacts when absolute positioned element with transform moves positions
Summary: Artifacts when absolute positioned element with transform moves positions
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.10
: P2 Normal
Assignee: zalan
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-01-07 06:34 PST by Carlos Liam
Modified: 2015-01-09 21:41 PST (History)
3 users (show)

See Also:


Attachments
Screenshot of the bug (144.60 KB, image/png)
2015-01-07 06:34 PST, Carlos Liam
no flags Details
Test reduction. (626 bytes, text/html)
2015-01-08 15:32 PST, zalan
no flags Details
Test with positioned descendant of the moving box (981 bytes, text/html)
2015-01-09 20:52 PST, Simon Fraser (smfr)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Liam 2015-01-07 06:34:51 PST
Created attachment 244155 [details]
Screenshot of the bug

I don't know exact specifics of the bug.

http://aarzee.me/stackinteractive.html

Click on the 'folder' icon and click and drag one of the colored icons (without switching positions with another icon) to reproduce.

If the element is NOT transformed while 'held' the artifacts do not appear.
Comment 1 Benjamin Poulain 2015-01-07 12:24:44 PST
I can reproduce on ToT. We don't repaint the invalidated area, resulting in stale pixels everywhere.
Comment 2 Radar WebKit Bug Importer 2015-01-07 12:35:44 PST
<rdar://problem/19402030>
Comment 3 Simon Fraser (smfr) 2015-01-07 13:59:23 PST
http://trac.webkit.org/log/trunk/?rev=151645&stop_rev=151626
Comment 4 zalan 2015-01-08 15:32:30 PST
Created attachment 244304 [details]
Test reduction.
Comment 5 Simon Fraser (smfr) 2015-01-09 20:18:27 PST
This happens because we repaint the layer in RenderLayerCompositor::updateBacking() after the style change that starts the transition. So the layer already has the new transform and transform origin.
Comment 6 Simon Fraser (smfr) 2015-01-09 20:49:54 PST
We can work around this by repainting using the layer's cached repaint rect I think.
Comment 7 Simon Fraser (smfr) 2015-01-09 20:52:00 PST
Created attachment 244401 [details]
Test with positioned descendant of the moving box
Comment 8 Simon Fraser (smfr) 2015-01-09 21:37:57 PST
Fix is something like this:

diff --git a/Source/WebCore/rendering/RenderLayer.cpp b/Source/WebCore/rendering/RenderLayer.cpp
index 1e9f4955775fa120f39cca40126296089e043746..8688273887be2d6dba3d741afe925a02071de05b 100644
--- a/Source/WebCore/rendering/RenderLayer.cpp
+++ b/Source/WebCore/rendering/RenderLayer.cpp
@@ -4094,12 +4094,14 @@ void RenderLayer::paintLayerContents(GraphicsContext* context, const LayerPainti
     bool needToAdjustSubpixelQuantization = setupFontSubpixelQuantization(context, didQuantizeFonts);
 
     // Apply clip-path to context.
-    bool hasClipPath = setupClipPath(context, paintingInfo, offsetFromRoot, rootRelativeBounds, rootRelativeBoundsComputed);
+    LayoutSize columnAwareOffsetFromRoot = toLayoutSize(convertToLayerCoords(paintingInfo.rootLayer, LayoutPoint(), AdjustForColumns));
+    bool hasClipPath = setupClipPath(context, paintingInfo, columnAwareOffsetFromRoot, rootRelativeBounds, rootRelativeBoundsComputed);
 
     LayerPaintingInfo localPaintingInfo(paintingInfo);
 
     GraphicsContext* transparencyLayerContext = context;
-    std::unique_ptr<FilterEffectRendererHelper> filterPainter = setupFilters(context, localPaintingInfo, paintFlags, offsetFromRoot, rootRelativeBounds, rootRelativeBoundsComputed);
+
+    std::unique_ptr<FilterEffectRendererHelper> filterPainter = setupFilters(context, localPaintingInfo, paintFlags, columnAwareOffsetFromRoot, rootRelativeBounds, rootRelativeBoundsComputed);
     if (filterPainter) {
         context = filterPainter->filterContext();
         if (context != transparencyLayerContext && haveTransparency) {
Comment 9 Simon Fraser (smfr) 2015-01-09 21:41:09 PST
Sorry, that was meant for another bug.