Modify supercluster multiplier logic.

Modify supercluster multiplier logic.

Previously the multiplier was based on the first root touched by the current
layout pass (for table cells) or the deepest common ancestor of all the roots
(for other superclusters).

We now base the multiplier on the max known width of any root.  This is still
not great since not all widths are known, but it gives us consistent results
on hacker news.

BUG=361749
R=pdr@chromium.org

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

[pdr., 2014-04-10 20:34:36]

My understanding is that this is for the case when we have a lot of content to
layout and we end up doing two layouts as the content loads. Is that what's
happening in the hackernews case? If so, don't we need to re-compute the
supercluster multiplier when a new cluster is added (and re-layout the entire
supercluster if there's a change)? I suspect there are other bugs in the
slow-loading case. Would it be possible to add a test for that?

[skobes, 2014-04-10 21:25:18]

On 2014/04/10 20:34:36, pdr wrote:
> My understanding is that this is for the case when we have a lot of content to
> layout and we end up doing two layouts as the content loads. Is that what's
> happening in the hackernews case? If so, don't we need to re-compute the
> supercluster multiplier when a new cluster is added (and re-layout the entire
> supercluster if there's a change)? I suspect there are other bugs in the
> slow-loading case. Would it be possible to add a test for that?

Fixing the general problem of inconsistent multipliers across layout passes will
be pretty hard, I am not sure how to do that.  This patch relies on the fact
that the first comment is also the widest (since it is not nested), so every
layout pass will see the same widest cluster root.

Do you have any suggestions for how to test the case of content broken into
multiple layouts?

[pdr., 2014-04-10 21:34:26]

On 2014/04/10 21:25:18, skobes wrote:
> On 2014/04/10 20:34:36, pdr wrote:
> > My understanding is that this is for the case when we have a lot of content
to
> > layout and we end up doing two layouts as the content loads. Is that what's
> > happening in the hackernews case? If so, don't we need to re-compute the
> > supercluster multiplier when a new cluster is added (and re-layout the
entire
> > supercluster if there's a change)? I suspect there are other bugs in the
> > slow-loading case. Would it be possible to add a test for that?
> 
> Fixing the general problem of inconsistent multipliers across layout passes
will
> be pretty hard, I am not sure how to do that.  This patch relies on the fact
> that the first comment is also the widest (since it is not nested), so every
> layout pass will see the same widest cluster root.
> 
> Do you have any suggestions for how to test the case of content broken into
> multiple layouts?

Ok, just making sure I understood the problem. I'd be okay with not fixing the
general problem, but I would like to test.

I think you can achieve this effect by just appending the content via JS. For
example:
// wait for first layout
window.requestAnimationFrame(function() {
    document.body.innerHTML += "new content";
    // force a new layout
    var forceLayout = document.body.offsetTop;
});

[skobes, 2014-04-11 01:58:51]

Added a test.

[pdr., 2014-04-11 02:02:22]

On 2014/04/11 01:58:51, skobes wrote:
> Added a test.

LGTM

[pdr., 2014-04-11 02:22:14]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2014-04-11 02:22:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skobes@chromium.org/231663006/40001

[commit-bot: I haz the power, 2014-04-11 02:22:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-11 02:22:25]

Failed to request the patch to try. Please note that binary files are still
unsupported at the moment, this is being worked on.

Thanks for your patience.

Transient error: Can't process patch for file
LayoutTests/platform/linux/fast/text-autosizing/supercluster-multiple-layout-expected.png.
Binary file is empty. Maybe the file wasn't uploaded in the first place?

[skobes, 2014-04-11 04:52:00]

The CQ bit was checked by skobes@chromium.org

[commit-bot: I haz the power, 2014-04-11 04:52:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skobes@chromium.org/231663006/60001

[commit-bot: I haz the power, 2014-04-11 04:52:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-11 04:52:31]

Failed to request the patch to try. Please note that binary files are still
unsupported at the moment, this is being worked on.

Thanks for your patience.

Transient error: Can't process patch for file
LayoutTests/platform/linux/virtual/fasttextautosizing/fast/text-autosizing/supercluster-multiple-layout-expected.png.
Binary file is empty. Maybe the file wasn't uploaded in the first place?

[skobes, 2014-04-11 04:57:08]

The CQ bit was checked by skobes@chromium.org

[commit-bot: I haz the power, 2014-04-11 04:57:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skobes@chromium.org/231663006/80001

[pdr., 2014-04-11 12:32:37]

The CQ bit was unchecked by pdr@chromium.org

[pdr., 2014-04-11 12:32:42]

The CQ bit was checked by pdr@chromium.org

[skobes, 2014-04-11 19:27:05]

The CQ bit was checked by skobes@chromium.org

[commit-bot: I haz the power, 2014-04-11 19:27:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skobes@chromium.org/231663006/100001

[skobes, 2014-04-11 20:06:15]

Committed patchset #6 manually as r171364 (presubmit successful).