Title: [116711] trunk/Source/WebCore
- Revision
- 116711
- Author
- [email protected]
- Date
- 2012-05-10 17:31:30 -0700 (Thu, 10 May 2012)
Log Message
https://bugs.webkit.org/show_bug.cgi?id=86158
Overlay scrollbars without layers never paint in overflow regions in
tiled drawing mode
-and corresponding-
<rdar://problem/11289546>
Reviewed by Darin Adler.
RenderLayers paint scrollbars that do not have their own layers by
running a second pass through the layer tree after the layer tree has
painted. This ensures that the scrollbars always paint on top of
content. However, this mechanism was relying on
FrameView::paintContents() as a choke-point for all painting to
trigger the second painting pass. That is not a reasonable choke-point
in tiled drawing, so this patch adds similar code to
RenderLayerBacking.
Only opt into the second painting pass for scrollbars that do not have
their own layers.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintOverflowControls):
A layer that paints into its backing cannot return early here if it
has overlay scrollbars to paint.
(WebCore::RenderLayer::paintLayer):
This replicates code in FrameView::paintContents(). After painting the
owning layer, do a second pass if there are overlay scrollbars to
paint.
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::paintIntoLayer):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (116710 => 116711)
--- trunk/Source/WebCore/ChangeLog 2012-05-11 00:19:57 UTC (rev 116710)
+++ trunk/Source/WebCore/ChangeLog 2012-05-11 00:31:30 UTC (rev 116711)
@@ -1,3 +1,37 @@
+2012-05-10 Beth Dakin <[email protected]>
+
+ https://bugs.webkit.org/show_bug.cgi?id=86158
+ Overlay scrollbars without layers never paint in overflow regions in
+ tiled drawing mode
+ -and corresponding-
+ <rdar://problem/11289546>
+
+ Reviewed by Darin Adler.
+
+ RenderLayers paint scrollbars that do not have their own layers by
+ running a second pass through the layer tree after the layer tree has
+ painted. This ensures that the scrollbars always paint on top of
+ content. However, this mechanism was relying on
+ FrameView::paintContents() as a choke-point for all painting to
+ trigger the second painting pass. That is not a reasonable choke-point
+ in tiled drawing, so this patch adds similar code to
+ RenderLayerBacking.
+
+ Only opt into the second painting pass for scrollbars that do not have
+ their own layers.
+ * rendering/RenderLayer.cpp:
+ (WebCore::RenderLayer::paintOverflowControls):
+
+ A layer that paints into its backing cannot return early here if it
+ has overlay scrollbars to paint.
+ (WebCore::RenderLayer::paintLayer):
+
+ This replicates code in FrameView::paintContents(). After painting the
+ owning layer, do a second pass if there are overlay scrollbars to
+ paint.
+ * rendering/RenderLayerBacking.cpp:
+ (WebCore::RenderLayerBacking::paintIntoLayer):
+
2012-05-10 Anders Carlsson <[email protected]>
Well, at least fixing the GTK+ build is something!
Modified: trunk/Source/WebCore/rendering/RenderLayer.cpp (116710 => 116711)
--- trunk/Source/WebCore/rendering/RenderLayer.cpp 2012-05-11 00:19:57 UTC (rev 116710)
+++ trunk/Source/WebCore/rendering/RenderLayer.cpp 2012-05-11 00:31:30 UTC (rev 116711)
@@ -2559,9 +2559,14 @@
// and we'll paint the scrollbars then. In the meantime, cache tx and ty so that the
// second pass doesn't need to re-enter the RenderTree to get it right.
if (hasOverlayScrollbars() && !paintingOverlayControls) {
+ m_cachedOverlayScrollbarOffset = paintOffset;
+#if USE(ACCELERATED_COMPOSITING)
+ // It's not necessary to do the second pass if the scrollbars paint into layers.
+ if ((m_hBar && layerForHorizontalScrollbar()) || (m_vBar && layerForVerticalScrollbar()))
+ return;
+#endif
RenderView* renderView = renderer()->view();
renderView->layer()->setContainsDirtyOverlayScrollbars(true);
- m_cachedOverlayScrollbarOffset = paintOffset;
renderView->frameView()->setContainsScrollableAreaWithOverlayScrollbars(true);
return;
}
@@ -2882,7 +2887,7 @@
// but we need to ensure that we don't cache clip rects computed with the wrong root in this case.
if (context->updatingControlTints() || (paintBehavior & PaintBehaviorFlattenCompositingLayers))
paintFlags |= PaintLayerTemporaryClipRects;
- else if (!backing()->paintsIntoWindow() && !backing()->paintsIntoCompositedAncestor() && !shouldDoSoftwarePaint(this, paintFlags & PaintLayerPaintingReflection)) {
+ else if (!backing()->paintsIntoWindow() && !backing()->paintsIntoCompositedAncestor() && !shouldDoSoftwarePaint(this, paintFlags & PaintLayerPaintingReflection) && !rootLayer->containsDirtyOverlayScrollbars()) {
// If this RenderLayer should paint into its backing, that will be done via RenderLayerBacking::paintIntoLayer().
return;
}
Modified: trunk/Source/WebCore/rendering/RenderLayerBacking.cpp (116710 => 116711)
--- trunk/Source/WebCore/rendering/RenderLayerBacking.cpp 2012-05-11 00:19:57 UTC (rev 116710)
+++ trunk/Source/WebCore/rendering/RenderLayerBacking.cpp 2012-05-11 00:31:30 UTC (rev 116711)
@@ -1169,6 +1169,9 @@
// FIXME: GraphicsLayers need a way to split for RenderRegions.
m_owningLayer->paintLayerContents(rootLayer, context, paintDirtyRect, paintBehavior, paintingRoot, 0, 0, paintFlags);
+ if (m_owningLayer->containsDirtyOverlayScrollbars())
+ m_owningLayer->paintOverlayScrollbars(context, paintDirtyRect, paintBehavior, paintingRoot);
+
ASSERT(!m_owningLayer->m_usedTransparency);
}
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
