Implement lazy block layout prototype behind a runtime flag.

Source/core/rendering/RenderLayer.cpp

Index: Source/core/rendering/RenderLayer.cpp
diff --git a/Source/core/rendering/RenderLayer.cpp b/Source/core/rendering/RenderLayer.cpp
index 661a6414e2cf06f70b56d94e570a16129c841be4..9ce524d8cf3878fc427e79aa477f8fd598c5a7ce 100644
--- a/Source/core/rendering/RenderLayer.cpp
+++ b/Source/core/rendering/RenderLayer.cpp
@@ -99,6 +99,7 @@
 #include "core/rendering/RenderInline.h"
 #include "core/rendering/RenderLayerBacking.h"
 #include "core/rendering/RenderLayerCompositor.h"
+#include "core/rendering/RenderLazyBlock.h"
 #include "core/rendering/RenderMarquee.h"
 #include "core/rendering/RenderReplica.h"
 #include "core/rendering/RenderScrollbar.h"
@@ -2340,6 +2341,8 @@ void RenderLayer::scrollTo(int x, int y)
             view->frameView()->updateAnnotatedRegions();
 
             view->updateWidgetPositions();
+
+            view->markLazyBlocksForLayout();

[ojan, 2013/04/26 00:41:16]

Doesn't not doing the layout here mean that paint might get stale output?

[esprehn, 2013/04/26 00:45:44]

I don't think it would be any worse than if you got ahead of the scroll. We'll
never be asked to paint() without being asked to layout() first from what I can
tell.

jamesr might know better.

[jamesr, 2013/04/26 00:58:03]

layout() is always called on before painting in the software and compositing
paths (via WebViewImpl::layout()). this does a top-level layout, but it doesn't
have any sort of geometry information currently. we just assume after calling
layout() it's safe to paint() anything anywhere in the render tree. we'll
obviously have to refine that down the road

         }
 
         if (!m_updatingMarqueePosition) {