Implement lazy block layout prototype behind a runtime flag.

Implement lazy block layout prototype behind a runtime flag.

This patch adds a new display type "lazy-block" that does a highly
constrained block layout that allows us to avoid laying out content
outside the viewport until we need it, and speeds up insertion/
removal of children both in and out of the viewport.

This is still in a prototype phase, and is being landed behind a
runtime flag that will default to off.

BUG=235595
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=149140

[esprehn, 2013-04-25 23:30:46]

LGTM.

[commit-bot: I haz the power, 2013-04-25 23:31:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/leviw@chromium.org/13937017/1

[commit-bot: I haz the power, 2013-04-25 23:49:38]

Retried try job too often on linux_layout_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_layo...

[leviw_travelin_and_unemployed, 2013-04-26 00:00:16]

Committed patchset #1 manually as r149140 (presubmit successful).

[ojan, 2013-04-26 00:41:15]

https://codereview.chromium.org/13937017/diff/1/Source/core/rendering/RenderL...
File Source/core/rendering/RenderLayer.cpp (right):

https://codereview.chromium.org/13937017/diff/1/Source/core/rendering/RenderL...
Source/core/rendering/RenderLayer.cpp:2345: view->markLazyBlocksForLayout();
Doesn't not doing the layout here mean that paint might get stale output?

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

https://codereview.chromium.org/13937017/diff/1/Source/core/rendering/RenderL...
File Source/core/rendering/RenderLayer.cpp (right):

https://codereview.chromium.org/13937017/diff/1/Source/core/rendering/RenderL...
Source/core/rendering/RenderLayer.cpp:2345: view->markLazyBlocksForLayout();
On 2013/04/26 00:41:16, ojan wrote:
> Doesn't not doing the layout here mean that paint might get stale output?

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]

https://codereview.chromium.org/13937017/diff/1/Source/core/rendering/RenderL...
File Source/core/rendering/RenderLayer.cpp (right):

https://codereview.chromium.org/13937017/diff/1/Source/core/rendering/RenderL...
Source/core/rendering/RenderLayer.cpp:2345: view->markLazyBlocksForLayout();
On 2013/04/26 00:45:44, esprehn wrote:
> On 2013/04/26 00:41:16, ojan wrote:
> > Doesn't not doing the layout here mean that paint might get stale output?
> 
> 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.

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

[eseidel, 2013-04-27 09:09:34]

I really hope I don't regret doing this on trunk. :)  I wish we had a real
git.chromium.org to use for awesome experiments like this.

https://codereview.chromium.org/13937017/diff/1/Source/core/page/FrameView.cpp
File Source/core/page/FrameView.cpp (right):

https://codereview.chromium.org/13937017/diff/1/Source/core/page/FrameView.cp...
Source/core/page/FrameView.cpp:1181: if (!renderView()->firstLazyBlock())
Is this expensive?