Remove minimumLayoutDelay() and associated machinery

Remove minimumLayoutDelay() and associated machinery

In the process of moving away from Blink scheduling its own layouts, it no longer makes sense to have artificial layout-avoidance checks in Blink.  If the embedder asks us to layout we should layout immediately.  The embedder should decide if it wants to delay posting a frame until the onload event, etc.

Blink no longer waits 250ms before allowing scheduled layouts.

Performance analysis:
https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AidRaO7Awc-DdGRRaWVsLWx5T0p4cUFLSUlkaEtvd2c
(editable by @chromium.org)

I'm separating this change out of the larger removal of the layout timer, in order to better contain the problem.

All of the LayoutTest result changes appear to be progressions.

The parser changes were necessary to keep javascript: urls synchronous.  It turns out we weren't actually parsing them synchronously if they were loading while isLayoutTimerActive (now parserShouldYieldAgressivelyBeforeFirstLayout) was true, it just happened to be the case that the timer would never be schedule for the first 250ms.  I believe if you had a page which took longer than 250ms to reach the onload event you could have ended up with a scheduled layout which would have caused incorrect behavior for javascript: urls.  Now we commonly schedule layouts immediately during loading and so were always hitting this case.

Our resizeEvent behavior was wrong, it just happened that the tests didn't notice as we weren't doing a layout() during the first 250ms.  It's possible we could have forced a layout during the resize-count tests which would have demonstrated the previously broken behavior.

The scrolling coordinator test looks like a progression to me.  The scrollbars are now correctly displaying on the region.  I suspect this is a bug in region code which was being tickled by our layout avoidance before.

The inlineBox test similarly had the wrong placement of the bullet.  The bullet isn't rendered, so it doesn't matter.  Presumably we have a bug where we were leaving the bullet needing layout while dumping before.

The svg-remote test also looks like a progression.  Likely a result of successive layouts negotiating the size with the nested SVG more correctly?

BUG=261689

[eseidel, 2013-07-25 00:59:18]

I believe this is ready for review.

[eseidel, 2013-07-25 01:07:16]

There is some perf risk for microbenchmarks to this change, as we may do more
layouts during page load than we did before.

When I move us to compositor-scheduled layouts, we'll of course do fewer.

If this change is deemed too risky, we can wait until then.  This was largely an
exercise in containing the problem.  I tried to move directly to
compositor-based layouts and had too much test fallout.

[esprehn, 2013-07-25 01:15:34]

LGTM

This looks great, is it going to cause us to do tons more layouts on page load
though?

https://codereview.chromium.org/20140002/diff/21001/Source/web/WebViewImpl.cpp
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/20140002/diff/21001/Source/web/WebViewImpl.cp...
Source/web/WebViewImpl.cpp:3393: // This paint invalidation should not be
necessary, but won't harm anything either.
FIXME

https://codereview.chromium.org/20140002/diff/21001/Source/web/WebViewImpl.cp...
Source/web/WebViewImpl.cpp:3402: // Unclear what this is doing. Callers may
actually need this code.
FIXME:

[eseidel, 2013-07-25 01:17:57]

I should chat with TonyG.  There may be an easy way to count layouts during load
with telemetry.

[tonyg, 2013-07-25 01:25:00]

On 2013/07/25 01:17:57, eseidel wrote:
> I should chat with TonyG.  There may be an easy way to count layouts during
load
> with telemetry.

Definitely. Edit tools/perf/measurements/loading.py and add this as the last
line:
     results.Add(key + '_num', 'ms', len(times))

I'd support checking that in.

Then:
$ tools/perf/run_measurement loading tools/perf/page_sets/top_25.json

[eseidel, 2013-07-25 07:44:56]

Assuming I did this right, the data does not look very favorable. :(

https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AidRaO7Awc-DdGRRa...

What interesting is that the load event is much faster for some sites and much
slower for others.  Overall we're doing more layouts of course.

[ojan, 2013-07-25 17:43:16]

Looks like most sites are a wash or faster (??? how's that possible). The
only big regression was gmail. Might be worth looking at that in about
tracing to see if there's something unexpected going on.


On Thu, Jul 25, 2013 at 12:44 AM, <eseidel@chromium.org> wrote:

> Assuming I did this right, the data does not look very favorable. :(
>
> https://docs.google.com/a/**chromium.org/spreadsheet/ccc?**
>
key=0AidRaO7Awc-**DdGRRaWVsLWx5T0p4cUFLSUlkaEtvd**2c#gid=1<https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AidRaO7Awc-DdGRRaWVsLWx5T0p4cUFLSUlkaEtvd2c#gid=1>
>
> What interesting is that the load event is much faster for some sites and
> much
> slower for others.  Overall we're doing more layouts of course.
>
>
https://codereview.chromium.**org/20140002/<https://codereview.chromium.org/2...
>

[jamesr, 2013-07-25 17:58:18]

I expect this'll trash the page cyclers and may cause lots of flashes.  While
this mechanism is not implemented perfectly, it serves a useful purpose.  The
basic thing this helps with is rendering "too early" when loading up a simple
page.  Consider a pure HTML+CSS page that takes 100ms to come down fully from
the network.  When we get the first packet of data, let's say that has the
<head> and a couple nodes in the <body>, we'll throw that into the tokenizer and
generate DOM nodes.  These will then request a style recalc to attach, which
fires off a zero-delay timer.  Once we compute styles and attach, we'll try to
request layout.  If we hit the minimum layout delay mechanism, nothing else
happens.  Otherwise, we'll schedule a layout immediately.  This has two
consequences:

1.) We'll do layout on a very incomplete DOM which will probably then be
immediately invalidated by the next packet of data
2.) More importantly, performing layout will generated invalidations which will
make the graphics system produce a frame with very little to no visible DOM.

Both are wasted work if we don't have anything useful to render yet.  Many
months back, the compositor frame scheduling wasn't respecting this system and
it lead to many user complaints about flashing white on page transitions.  I
tweaked the compositor to avoid producing frames in cases where we were limited
by this delay and many of the white flashes went away and the page cycler
performance shot up.

That said, this mechanism is not perfect.  It only gates scheduling layouts, but
anything that generates an invalidation directly (such as running JS) will
bypass it and cause us to put frames up "early" compared to when we would
otherwise want to.  250ms-or-end-of-main-resource is also probably not the right
threshold for the set of computers+networks we run on today and should be
tweaked.  The delaying is also probably not in the right place, although it has
to be done somewhere that's aware of our progress on the main resource.  The
system is probably also buggy in various ways since it's such a subtle and
poorly tested area.

[esprehn, 2013-07-25 17:58:36]

On 2013/07/25 17:43:16, ojan wrote:
> Looks like most sites are a wash or faster (??? how's that possible). The
> only big regression was gmail. Might be worth looking at that in about
> tracing to see if there's something unexpected going on.
> 

jamesr also brought up a good point that he thinks this is going to cause a lot
of FOUC. Have you tried browsing around with it?

[jamesr, 2013-07-25 18:00:55]

On 2013/07/25 07:44:56, eseidel wrote:
> Assuming I did this right, the data does not look very favorable. :(
> 
>
https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AidRaO7Awc-DdGRRa...
> 
> What interesting is that the load event is much faster for some sites and much
> slower for others.  Overall we're doing more layouts of course.

To understand this, what I've found most helpful is picking some sites that are
significantly different and carefully studying before and after traces.  When
doing the compositor scheduling tweaks I found that most of the page cycler
changes were due to changing the ordering of when actions were happening
relative to each other (i.e. painting before load instead of after, doing
sequences of small layouts instead of one big one, etc).

[eseidel, 2014-02-07 01:23:12]

Adam did this in https://codereview.chromium.org/156943004/.