[New Multicolumn] Never composite flow threads.

[New Multicolumn] Never composite flow threads.

This will prevent flow threads from becoming paint invalidation containers.

There's an assertion in LayoutFlowThread::mapRectToPaintInvalidationBacking()
on the paint invalidation container not being the flow thread. The (very
recent) fix for issue 481663 also tried to avoid this assertion, but obviously
didn't manage to catch all cases.

BUG=482420
R=chrishtr@chromium.org,dsinclair@chromium.org,wangxianzhu@chromium.org

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

[mstensho (USE GERRIT), 2015-04-29 13:57:41]

I'm starting to have doubts about this approach. What I'm trying to achieve is
for a flow thread to never _want_ to become composited. I may have found and
fixed all cases now, but maybe it would be better to just return false from
DeprecatedPaintLayerCompositor::canBeComposited() if it's a flow thread?

Let me know. If you prefer that to this CL, just !l-g-t-m it and I'll file
another one.

[dsinclair, 2015-04-29 14:04:17]

dsinclair@chromium.org changed reviewers:
+ leviw@chromium.org, wangxianzhu@chromium.org

[dsinclair, 2015-04-29 14:04:18]

+leviw, +wangxianzhu for paint invalidation container knowledge.

[Xianzhu, 2015-04-29 16:09:55]

wangxianzhu@chromium.org changed reviewers:
+ chrishtr@chromium.org

[Xianzhu, 2015-04-29 16:09:55]

Actually we'll deprecate paint invalidation container in slimming paint phase 2.

For now, I'd prefer changing DeprecatedPaintLayerCompositor::canBeComposited()
to prevent compositing of flow threads.

Also +chrishtr who has knowledge of compositing decision.

[chrishtr, 2015-04-29 17:36:18]

On 2015/04/29 at 16:09:55, wangxianzhu wrote:
> Actually we'll deprecate paint invalidation container in slimming paint phase
2.
> 
> For now, I'd prefer changing DeprecatedPaintLayerCompositor::canBeComposited()
to prevent compositing of flow threads.
> 
> Also +chrishtr who has knowledge of compositing decision.

I agree, this sounds like the best short-term solution.

[mstensho (USE GERRIT), 2015-04-29 19:05:11]

On 2015/04/29 17:36:18, chrishtr wrote:
> On 2015/04/29 at 16:09:55, wangxianzhu wrote:
> > Actually we'll deprecate paint invalidation container in slimming paint
phase
> 2.
> > 
> > For now, I'd prefer changing
DeprecatedPaintLayerCompositor::canBeComposited()
> to prevent compositing of flow threads.
> > 
> > Also +chrishtr who has knowledge of compositing decision.
> 
> I agree, this sounds like the best short-term solution.

All right. I'll do that. I'll just re-use this CL, instead of filing a new one.

[mstensho (USE GERRIT), 2015-04-29 19:12:43]

On 2015/04/29 19:05:11, mstensho wrote:
> On 2015/04/29 17:36:18, chrishtr wrote:
> > On 2015/04/29 at 16:09:55, wangxianzhu wrote:
> > > Actually we'll deprecate paint invalidation container in slimming paint
> phase
> > 2.
> > > 
> > > For now, I'd prefer changing
> DeprecatedPaintLayerCompositor::canBeComposited()
> > to prevent compositing of flow threads.
> > > 
> > > Also +chrishtr who has knowledge of compositing decision.
> > 
> > I agree, this sounds like the best short-term solution.
> 
> All right. I'll do that. I'll just re-use this CL, instead of filing a new
one.

Done. Please have a look.

[chrishtr, 2015-04-29 21:09:16]

This passes all other layout tests I guess?

[chrishtr, 2015-04-29 21:09:58]

On 2015/04/29 at 21:09:16, chrishtr wrote:
> This passes all other layout tests I guess?

Also please update the description.

Should you delete the other code to reduce the need for compositing that you
previously added in other patches? (Sounds like there was some?)

[mstensho (USE GERRIT), 2015-04-29 21:28:59]

On 2015/04/29 21:09:58, chrishtr wrote:
> On 2015/04/29 at 21:09:16, chrishtr wrote:
> > This passes all other layout tests I guess?

I sure hope so (only ran multicol tests locally; all fine). :)
I'll start another try job now and see if the tree is in a better shape (it
didn't even compile last time I tried).

> Also please update the description.

Of course! Done. (Already had the update stored locally, since the editor here
sucks more than both vim or emacs, but forgot to modify the actual review)
 
> Should you delete the other code to reduce the need for compositing that you
> previously added in other patches? (Sounds like there was some?)

There was one other patch [1], but that one actually fixed a rendering bug, and
the fact that it no longer turned a flow thread into a paint invalidation
container was just a side-effect. So, better keep it.

[1] https://codereview.chromium.org/1112593002

[chrishtr, 2015-04-29 21:41:02]

lgtm

[mstensho (USE GERRIT), 2015-04-29 21:43:26]

The CQ bit was checked by mstensho@opera.com

[commit-bot: I haz the power, 2015-04-29 21:43:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1109383002/40001

[commit-bot: I haz the power, 2015-04-30 00:07:01]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=194680