Simplify CompositingReasonFinder::requiresCompositingForFrame

Simplify CompositingReasonFinder::requiresCompositingForFrame

This CL removes an optimization whereby 0x0 iframes wouldn't get a composited
layer even if they would otherwise have been composited. This optimization was
causing a bunch of awkwardness because it introduced a dependency on layout
information in the CompositingReasonFinder, which caused the reason finder to
need to set a dirty bit in the RenderLayerCompositor.

This CL also prepares us to remove requiresCompositingForFrame into a
RenderPart-specific override of additionalCompositingReasons (after
https://codereview.chromium.org/197533013/ lands).

This CL also changes RenderLayerCompositor::enableCompositingMode to notify
iframes when the root layer is destroyed as well instead of relying upon the
CompositingReasonFinder to write the dirty bit.

R=vollick@chromium.org

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

[Ian Vollick, 2014-03-20 18:20:15]

On 2014/03/20 18:05:12, abarth wrote:

lgtm!

[abarth-chromium, 2014-03-20 18:22:21]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-03-20 18:22:31]

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

[ojan, 2014-03-20 18:43:48]

The 0x0 bit came from https://bugs.webkit.org/show_bug.cgi?id=34009. It seems
like some real sites hit this: https://bugs.webkit.org/show_bug.cgi?id=34009#c4.

I like getting rid of the 0x0 hack here, but I wonder if we need to add it in
somewhere else (e.g. computeCompositingRequirements could check this in addition
to overlap).

[commit-bot: I haz the power, 2014-03-20 19:18:21]

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

[commit-bot: I haz the power, 2014-03-20 19:18:22]

List of reviewers changed. ojan@chromium.org did a drive-by without LGTM'ing!

[abarth-chromium, 2014-03-20 19:23:43]

On 2014/03/20 18:43:48, ojan wrote:
> The 0x0 bit came from https://bugs.webkit.org/show_bug.cgi?id=34009. It seems
> like some real sites hit this:
https://bugs.webkit.org/show_bug.cgi?id=34009#c4.

The world was different then.  Now we run in compositing mode all the time, so
producing a 0x0 graphics layer isn't such a big deal.

[abarth-chromium, 2014-03-20 19:23:50]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-03-20 19:23:56]

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

[commit-bot: I haz the power, 2014-03-20 19:24:28]

Change committed as 169679

[ojan, 2014-03-20 19:33:06]

On 2014/03/20 19:23:43, abarth wrote:
> On 2014/03/20 18:43:48, ojan wrote:
> > The 0x0 bit came from https://bugs.webkit.org/show_bug.cgi?id=34009. It
seems
> > like some real sites hit this:
> https://bugs.webkit.org/show_bug.cgi?id=34009#c4.
> 
> The world was different then.  Now we run in compositing mode all the time, so
> producing a 0x0 graphics layer isn't such a big deal.

Since we expand the absoluteBounds to 1x1 in the overlap testing, this can mean
that we create extra layers due to overlapping the 0x0 layer. But maybe we
should worry about that if we see it on real pages? Also, maybe we should fix
overlap testing to not expand empty rects to 0x0.

In either case, I didn't intend to block the CQ. Was just trying to drive-by
comment. Silly rietveld. :(