Bug 102826 - [CSS Regions] Elements using transforms are not repainted correctly when rendered in a region
Summary: [CSS Regions] Elements using transforms are not repainted correctly when rend...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alexandru Chiculita
URL:
Keywords: AdobeTracked
Depends on:
Blocks: 57312
  Show dependency treegraph
 
Reported: 2012-11-20 10:50 PST by Alexandru Chiculita
Modified: 2012-11-28 13:39 PST (History)
8 users (show)

See Also:


Attachments
test case (1.98 KB, text/html)
2012-11-20 10:51 PST, Alexandru Chiculita
no flags Details
Patch V1 (6.62 KB, patch)
2012-11-20 15:18 PST, Alexandru Chiculita
no flags Details | Formatted Diff | Diff
Follow up patch (1.53 KB, patch)
2012-11-28 13:39 PST, Alexandru Chiculita
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandru Chiculita 2012-11-20 10:50:24 PST
Elements with RenderLayers do not repaint correctly. See the attached test case.
Comment 1 Alexandru Chiculita 2012-11-20 10:51:54 PST
Created attachment 175246 [details]
test case
Comment 2 Alexandru Chiculita 2012-11-20 15:18:10 PST
There are two separate issues in here:
1. When the <p> element is first created it will trigger a composited layer. Composited layers are disabled on the elements inside the flow, but when the style is first set on the just created RenderObject the flag "inRenderFlowThread" is not set yet. I've added https://bugs.webkit.org/show_bug.cgi?id=102839 to fix it.

2. When a composited layer is created, then the whole page becomes a composited layer too. That means that the parent repaint container will always be the page. Our check for the parent RenderFlowThread will always fail in this case because we already found a repaint container. This patch will fix that case.
Comment 3 Alexandru Chiculita 2012-11-20 15:18:34 PST
Created attachment 175289 [details]
Patch V1
Comment 4 Dave Hyatt 2012-11-27 14:14:46 PST
Comment on attachment 175289 [details]
Patch V1

View in context: https://bugs.webkit.org/attachment.cgi?id=175289&action=review

r=me

> Source/WebCore/rendering/RenderObject.cpp:1293
> -    // Return the flow thread as a repaint container in order to create a chokepoint that allows us to change
> +    // Return the flow thread as a repaint container in order to create a checkpoint that allows us to change

Not sure why you're changing this. "chokepoint" is a much more accurate term to describe this than "checkpoint"
Comment 5 WebKit Review Bot 2012-11-27 14:24:12 PST
Comment on attachment 175289 [details]
Patch V1

Clearing flags on attachment: 175289

Committed r135921: <http://trac.webkit.org/changeset/135921>
Comment 6 WebKit Review Bot 2012-11-27 14:24:16 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 Alexandru Chiculita 2012-11-27 15:09:22 PST
(In reply to comment #4)
> (From update of attachment 175289 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=175289&action=review
> 
> r=me
> 
> > Source/WebCore/rendering/RenderObject.cpp:1293
> > -    // Return the flow thread as a repaint container in order to create a chokepoint that allows us to change
> > +    // Return the flow thread as a repaint container in order to create a checkpoint that allows us to change
> 
> Not sure why you're changing this. "chokepoint" is a much more accurate term to describe this than "checkpoint"

Hm, right. My editor suggested the correction, so I just accepted it. The patch already landed, but will make a simple unreviewed patch for it.
Comment 8 Alexandru Chiculita 2012-11-28 13:39:10 PST
Created attachment 176562 [details]
Follow up patch

Follow up update after the original patch was landed by commit queue.

Landed manually in http://trac.webkit.org/changeset/136054.