RESOLVED FIXED48570
iframes forced into slow scrolling mode by containing RenderLayer sometimes 
https://bugs.webkit.org/show_bug.cgi?id=48570
Summary iframes forced into slow scrolling mode by containing RenderLayer sometimes
James Robinson
Reported 2010-10-28 15:37:42 PDT
With this HTML the interior iframe blits while scrolling: <!DOCTYPE html> <html style='overflow:hidden'> <body style=''> <iframe src="http://webkit.org"> however with this HTML the interior frame is forced into the slow scrolling path: <!DOCTYPE html> <html style='overflow:hidden'> <body style='overflow:hidden'> <iframe src="http://webkit.org"> I believe the body's RenderLayer is setting the isOverlapped flag on the iframe's FrameView. This issue has been affecting GMail, causing all scrolling to require a full repaint. The GMail team is adjusting their CSS to avoid this issue, but it's likely this is affecting more websites.
Attachments
Patch (5.70 KB, patch)
2010-10-28 17:27 PDT, James Robinson 		no flags
DetailsFormatted DiffDiff
Patch (7.57 KB, patch)
2010-10-28 17:33 PDT, James Robinson 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
James Robinson
Comment 1 2010-10-28 15:43:30 PDT
Better reduction: <!DOCTYPE html> <html style='overflow:hidden'> <body style=''> <iframe src="data:text/html;charset=utf-8,<!DOCTYPE html><html style='background-color:#eeeeee'><div style='height:500px'>"> the iframe's contents have to be opaque to go down the fast scrolling path, of course :)
James Robinson
Comment 2 2010-10-28 16:03:55 PDT
Layer tree dump: layer 0x7ff0e0204dd8 at (0,0) size 1267x1023 RenderView 0x7ff0ebfab018 at (0,0) size 1267x1023 positive z-order list(1) layer 0x7ff0ba58ddd8 at (0,0) size 1267x175 RenderBlock 0x7ff0ebf87b78 {HTML} at (0,0) size 1267x175 normal flow list(1) layer 0x7ff0e02ae018 at (8,8) size 1251x159 RenderBody 0x7ff0ebf872b8 {BODY} at (8,8) size 1251x159 RenderPartObject 0x7ff0e02a9718 {IFRAME} at (0,0) size 304x154 [border: (2px inset #000000)] layer 0x7ff0ba58d798 at (0,0) size 285x516 RenderView 0x7ff0bab29018 at (0,0) size 285x150 positive z-order list(1) layer 0x7ff0ba59ca18 at (0,0) size 285x516 RenderBlock 0x7ff0e02151d8 {HTML} at (0,0) size 285x516 [bgcolor=#EEEEEE] RenderBody 0x7ff0e02a97f8 {BODY} at (8,8) size 269x500 RenderBlock 0x7ff0e0215d38 {DIV} at (0,0) size 269x500 The layer 0x7ff0e02ae018 (the body's layer it appears) is setting the isOverlapped flag on (WebCore::RenderIFrame *) 0x7ff0e02a9718.
James Robinson
Comment 3 2010-10-28 16:31:15 PDT
I think painting is 'escaping' its RL: #0 WebCore::RenderWidget::paint (this=0x7ff0e02a9718, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/RenderWidget.cpp:306 #1 0x0000000002822a0b in WebCore::InlineBox::paint (this=0x7ff0bb4055b8, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/InlineBox.cpp:180 #2 0x00000000028270cc in WebCore::InlineFlowBox::paint (this=0x7ff0e0220d98, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/InlineFlowBox.cpp:737 #3 0x000000000294743c in WebCore::RootInlineBox::paint (this=0x7ff0e0220d98, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/RootInlineBox.cpp:178 #4 0x00000000028d2ebc in WebCore::RenderLineBoxList::paint (this=0x7ff0ebf87360, renderer=0x7ff0ebf872b8, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/RenderLineBoxList.cpp:224 #5 0x000000000283fd0a in WebCore::RenderBlock::paintContents (this=0x7ff0ebf872b8, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/RenderBlock.cpp:2230 #6 0x00000000028405e3 in WebCore::RenderBlock::paintObject (this=0x7ff0ebf872b8, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/RenderBlock.cpp:2341 #7 0x000000000283f48a in WebCore::RenderBlock::paint (this=0x7ff0ebf872b8, paintInfo=..., tx=8, ty=8) at third_party/WebKit/WebCore/rendering/RenderBlock.cpp:2121 #8 0x0000000002840106 in WebCore::RenderBlock::paintChildren (this=0x7ff0ebf87b78, paintInfo=..., tx=0, ty=0) at third_party/WebKit/WebCore/rendering/RenderBlock.cpp:2274 #9 0x000000000283fd25 in WebCore::RenderBlock::paintContents (this=0x7ff0ebf87b78, paintInfo=..., tx=0, ty=0) at third_party/WebKit/WebCore/rendering/RenderBlock.cpp:2232 #10 0x00000000028405e3 in WebCore::RenderBlock::paintObject (this=0x7ff0ebf87b78, paintInfo=..., tx=0, ty=0) at third_party/WebKit/WebCore/rendering/RenderBlock.cpp:2341 #11 0x000000000283f48a in WebCore::RenderBlock::paint (this=0x7ff0ebf87b78, paintInfo=..., tx=0, ty=0) at third_party/WebKit/WebCore/rendering/RenderBlock.cpp:2121 #12 0x00000000028b6e2e in WebCore::RenderLayer::paintLayer (this=0x7ff0ba58ddd8, rootLayer=0x7ff0e0204dd8, p=0x7fffaef08970, paintDirtyRect=..., paintBehavior=0, paintingRoot=0x0, overlapTestRequests=0x7fffaef08620, paintFlags=0) at third_party/WebKit/WebCore/rendering/RenderLayer.cpp:2489 #13 0x00000000028b7252 in WebCore::RenderLayer::paintList (this=0x7ff0e0204dd8, list=0x7ff0bab40920, rootLayer=0x7ff0e0204dd8, p=0x7fffaef08970, paintDirtyRect=..., paintBehavior=0, paintingRoot=0x0, overlapTestRequests=0x7fffaef08620, paintFlags=0) at third_party/WebKit/WebCore/rendering/RenderLayer.cpp:2542 #14 0x00000000028b7033 in WebCore::RenderLayer::paintLayer (this=0x7ff0e0204dd8, rootLayer=0x7ff0e0204dd8, p=0x7fffaef08970, paintDirtyRect=..., paintBehavior=0, paintingRoot=0x0, overlapTestRequests=0x7fffaef08620, paintFlags=0) at third_party/WebKit/WebCore/rendering/RenderLayer.cpp:2510 #15 0x00000000028b6109 in WebCore::RenderLayer::paint (this=0x7ff0e0204dd8, p=0x7fffaef08970, damageRect=..., paintBehavior=0, paintingRoot=0x0) at third_party/WebKit/WebCore/rendering/RenderLayer.cpp:2295 #16 0x00000000027cde70 in WebCore::FrameView::paintContents (this=0x7ff0ec02b000, p=0x7fffaef08970, rect=...) at third_party/WebKit/WebCore/page/FrameView.cpp:2024 #17 0x00000000023d8d20 in WebCore::ScrollView::paint (this=0x7ff0ec02b000, context=0x7fffaef08970, rect=...) at third_party/WebKit/WebCore/platform/ScrollView.cpp:840 Frame #12 is the RenderLayer::paint() for the 0x7ff0ba58ddd8 RenderLayer. The renderer()->paint() call is ending up in the RenderWidget::paint() function for the RenderIFrame 0x7ff0e02a9718. However the RenderLayer for that RO is not 0x7ff0ba58ddd8: call this->enclosingLayer() $21 = (class WebCore::RenderLayer *) 0x7ff0e02ae018
James Robinson
Comment 4 2010-10-28 16:42:52 PDT
Dave pointed out in IRC that the relevant RenderLayer is not the enclosing RL but the enclosing self-painting RenderLayer, which for the RenderIFrame is indeed 0x7ff0ba58ddd8.
James Robinson
Comment 5 2010-10-28 17:27:06 PDT
Created attachment 72269 [details] Patch
Simon Fraser (smfr)
Comment 6 2010-10-28 17:31:40 PDT
Comment on attachment 72269 [details] Patch No changelog!
James Robinson
Comment 7 2010-10-28 17:33:22 PDT
Created attachment 72271 [details] Patch
James Robinson
Comment 8 2010-10-28 17:36:23 PDT
Foiled by webkit-patch upload. Again, with ChangeLogs this time. I've confirmed this doesn't regress anything in fast/repaint with -p on my snow leopard box. I'll try running on all of fast/ just to be double sure but it'll take a while to filter out the false positives in the pixel expectations.
James Robinson
Comment 9 2010-10-28 18:03:21 PDT
On SL the only test in fast/ that changes behavior with -p --tolerance 0.1 with this patch is fast/repaint/iframe-scroll-repaint.html
James Robinson
Comment 10 2010-10-28 21:30:46 PDT
Comment on attachment 72271 [details] Patch Thanks for the fast review.
WebKit Commit Bot
Comment 11 2010-10-28 21:48:53 PDT
Comment on attachment 72271 [details] Patch Clearing flags on attachment: 72271 Committed r70840: <http://trac.webkit.org/changeset/70840>
WebKit Commit Bot
Comment 12 2010-10-28 21:48:59 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.