Title: [158727] trunk
- Revision
- 158727
- Author
- [email protected]
- Date
- 2013-11-05 23:31:52 -0800 (Tue, 05 Nov 2013)
Log Message
Widget's position change should not initiate layout, only when its size changes.
https://bugs.webkit.org/show_bug.cgi?id=123860
Reviewed by Andreas Kling.
RenderWidgets initiate unnecessary layouts while scrolling when they are embedded to
overflow:scroll containers. Scroll position change doesn't dirty the render tree
so it should not trigger layout either.
.:
* ManualTests/layouts-on-renderwidgets-while-scrolling.html: Added.
Source/WebCore:
Manual test added. Unfortunately we can't test against the number of layouts yet.
* rendering/RenderWidget.cpp:
(WebCore::RenderWidget::setWidgetGeometry):
(WebCore::RenderWidget::updateWidgetGeometry):
(WebCore::RenderWidget::updateWidgetPosition):
Modified Paths
Added Paths
Diff
Modified: trunk/ChangeLog (158726 => 158727)
--- trunk/ChangeLog 2013-11-06 07:30:55 UTC (rev 158726)
+++ trunk/ChangeLog 2013-11-06 07:31:52 UTC (rev 158727)
@@ -1,3 +1,16 @@
+2013-11-05 Zalan Bujtas <[email protected]>
+
+ Widget's position change should not initiate layout, only when its size changes.
+ https://bugs.webkit.org/show_bug.cgi?id=123860
+
+ Reviewed by Andreas Kling.
+
+ RenderWidgets initiate unnecessary layouts while scrolling when they are embedded to
+ overflow:scroll containers. Scroll position change doesn't dirty the render tree
+ so it should not trigger layout either.
+
+ * ManualTests/layouts-on-renderwidgets-while-scrolling.html: Added.
+
2013-11-05 Éva Balázsfalvi <[email protected]>
Remove leftover Qt related things from WebKitMacros.cmake
Added: trunk/ManualTests/layouts-on-renderwidgets-while-scrolling.html (0 => 158727)
--- trunk/ManualTests/layouts-on-renderwidgets-while-scrolling.html (rev 0)
+++ trunk/ManualTests/layouts-on-renderwidgets-while-scrolling.html 2013-11-06 07:31:52 UTC (rev 158727)
@@ -0,0 +1,26 @@
+<!doctype html>
+<html>
+<head>
+ <style>
+ html, body {
+ height: 100%;
+ }
+
+ .container {
+ height: 100%;
+ overflow: scroll;
+ }
+ iframe {
+ display: block;
+ width: 200px;
+ height: 600px;
+ }
+ </style>
+</head>
+<body>
+ <div class="container">
+ <iframe src="" this out of the view."></iframe>
+ <iframe src="" here and inspect if layouts got initiated, while scolling in the Web Inspector."></iframe>
+ </div>
+</body>
+</html>
Modified: trunk/Source/WebCore/ChangeLog (158726 => 158727)
--- trunk/Source/WebCore/ChangeLog 2013-11-06 07:30:55 UTC (rev 158726)
+++ trunk/Source/WebCore/ChangeLog 2013-11-06 07:31:52 UTC (rev 158727)
@@ -1,3 +1,21 @@
+2013-11-05 Zalan Bujtas <[email protected]>
+
+ Widget's position change should not initiate layout, only when its size changes.
+ https://bugs.webkit.org/show_bug.cgi?id=123860
+
+ Reviewed by Andreas Kling.
+
+ RenderWidgets initiate unnecessary layouts while scrolling when they are embedded to
+ overflow:scroll containers. Scroll position change doesn't dirty the render tree
+ so it should not trigger layout either.
+
+ Manual test added. Unfortunately we can't test against the number of layouts yet.
+
+ * rendering/RenderWidget.cpp:
+ (WebCore::RenderWidget::setWidgetGeometry):
+ (WebCore::RenderWidget::updateWidgetGeometry):
+ (WebCore::RenderWidget::updateWidgetPosition):
+
2013-11-05 Ryosuke Niwa <[email protected]>
Use-after-free in SliderThumbElement::dragFrom
Modified: trunk/Source/WebCore/rendering/RenderWidget.cpp (158726 => 158727)
--- trunk/Source/WebCore/rendering/RenderWidget.cpp 2013-11-06 07:30:55 UTC (rev 158726)
+++ trunk/Source/WebCore/rendering/RenderWidget.cpp 2013-11-06 07:31:52 UTC (rev 158727)
@@ -118,9 +118,10 @@
bool RenderWidget::setWidgetGeometry(const LayoutRect& frame)
{
IntRect clipRect = roundedIntRect(enclosingLayer()->childrenClipRect());
- IntRect newFrame = roundedIntRect(frame);
+ IntRect newFrameRect = roundedIntRect(frame);
+ IntRect oldFrameRect = m_widget->frameRect();
bool clipChanged = m_clipRect != clipRect;
- bool boundsChanged = m_widget->frameRect() != newFrame;
+ bool boundsChanged = oldFrameRect != newFrameRect;
if (!boundsChanged && !clipChanged)
return false;
@@ -130,7 +131,7 @@
WeakPtr<RenderWidget> weakThis = createWeakPtr();
// These calls *may* cause this renderer to disappear from underneath...
if (boundsChanged)
- m_widget->setFrameRect(newFrame);
+ m_widget->setFrameRect(newFrameRect);
else if (clipChanged)
m_widget->clipRectChanged();
// ...so we follow up with a sanity check.
@@ -138,19 +139,18 @@
return true;
#if USE(ACCELERATED_COMPOSITING)
- if (hasLayer() && layer()->isComposited())
+ if (boundsChanged && hasLayer() && layer()->isComposited())
layer()->backing()->updateAfterWidgetResize();
#endif
-
- return boundsChanged;
+ return oldFrameRect.size() != newFrameRect.size();
}
bool RenderWidget::updateWidgetGeometry()
{
- LayoutRect contentBox = contentBoxRect();
if (!m_widget->transformsAffectFrameRect())
return setWidgetGeometry(absoluteContentBox());
+ LayoutRect contentBox = contentBoxRect();
LayoutRect absoluteContentBox(localToAbsoluteQuad(FloatQuad(contentBox)).boundingBox());
if (m_widget->isFrameView()) {
contentBox.setLocation(absoluteContentBox.location());
@@ -316,18 +316,16 @@
return;
WeakPtr<RenderWidget> weakThis = createWeakPtr();
-
- bool boundsChanged = updateWidgetGeometry();
-
+ bool widgetSizeChanged = updateWidgetGeometry();
if (!weakThis)
return;
- // if the frame bounds got changed, or if view needs layout (possibly indicating
- // content size is wrong) we have to do a layout to set the right widget size
- if (m_widget && m_widget->isFrameView()) {
+ // if the frame size got changed, or if view needs layout (possibly indicating
+ // content size is wrong) we have to do a layout to set the right widget size.
+ if (m_widget->isFrameView()) {
FrameView* frameView = toFrameView(m_widget.get());
// Check the frame's page to make sure that the frame isn't in the process of being destroyed.
- if ((boundsChanged || frameView->needsLayout()) && frameView->frame().page())
+ if ((widgetSizeChanged || frameView->needsLayout()) && frameView->frame().page())
frameView->layout();
}
}
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
