Make Blink stop scheduling its own Layout, and use the compositor's timer instead

Make Blink stop scheduling its own Layout, and use the compositor's timer instead

This works, and is ready for landing.  Unfortunately it's likely to cause a long-tail of subtle timing bugs which may require several weeks to shake out.  I suspect I'll have to add a runtime flag to land this so we can easily turn it on/off in the tree (as we did with the HTML threaded parser for so many weeks after landing).

BUG=261689

[eseidel, 2013-07-19 22:54:19]

The cursor blink problems were actually just bug 262343

[eseidel, 2013-07-29 19:57:14]

So this is actually ready that it could be landed.  It breaks loading of
weather.com in the top25, but I think that may be bad interaction with the wpr
file (likely changes the load order of plugins), not necessarily a bug with the
patch.

Probably the best way to get this landed would be to instead add a runtime flag,
land it with the flag off, and then flip the flag separately.  I suspect there
will be fallout from this change which we'll only detect once we have it in the
tree.

Unfortunately this doesn't actually solve issue 261439 so I'm less excited about
actually landing it. :(

I think I will spend some time investigating other changes to actually make
those .cn sites spend less time in layout before signing myself up to fight with
this change for another few weeks.

[eseidel, 2013-07-29 20:00:39]

It's also possible that the weather.com (wpr-only!) failure is a bad interaction
with the minimumLayoutDelay().  In an earlier version of this patch I removed
the minimumLayoutDelay() code as it's not really compatible with the idea of
compositor-scheduled layouts.  But I instead broke that out into issue 20140002
(which is also probably ready for landing).

[nduca, 2013-08-04 22:32:26]

Just as an aside, I love this patch because it brings up a basic question I've
always had.. this is the current compositor flow:

call animate() on WebViewImpl -> services scripted animations on the frame views
call layout() on WebViewImpl
::paint all the layers

As a dumb question, would it be more appropriate to run recalc after the
scripted animations run? Is there any need to run before? Same goes for graphics
layer updates.

</driveby>

[esprehn, 2013-08-13 00:23:45]

On 2013/08/04 22:32:26, nduca wrote:
> Just as an aside, I love this patch because it brings up a basic question I've
> always had.. this is the current compositor flow:
> 
> call animate() on WebViewImpl -> services scripted animations on the frame
views
> call layout() on WebViewImpl
> ::paint all the layers
> 
> As a dumb question, would it be more appropriate to run recalc after the
> scripted animations run? Is there any need to run before? Same goes for
graphics
> layer updates.
> 

Which recalc do you mean? We already run style recalc and layout after scripted
animations run.

[esprehn, 2013-12-02 05:00:22]

Closing this issue, we should revisit this eventually, but I think we should
start with recalcStyle first.

[eseidel, 2013-12-02 05:34:56]

I came very close with this patch, learned a lot, and fixed a few various bugs. 
I suspect this was within a week of landing.  But we can certainly do recalc
style first. :)

[esprehn, 2013-12-02 05:51:21]

On 2013/12/02 05:34:56, eseidel wrote:
> I came very close with this patch, learned a lot, and fixed a few various
bugs. 
> I suspect this was within a week of landing.  But we can certainly do recalc
> style first. :)

If you can make this land then please do it! I was just closing issues that had
been open so long without an update where the patch could no longer apply to
clear out my codereview page. It's gotten soooo long.