Early return in RenderLayerCompositor::updateForceCompositingMode.

Early return in RenderLayerCompositor::updateForceCompositingMode.

We're hitting an assert in requiresCompositingForScrollableFrame,
because it depends on layout information. With
http://src.chromium.org/viewvc/blink?revision=171366&view=revision,
we now try to update this state when setting forceCompositingMode,
at which point, layout is not necessarily up to date.

We can just early return here because this method will be called
again after we've done the layout. This does potentially expose
us to bugs from chicken-egg issues that depend on the
m_forceCompositingMode bit for subframes.

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

[ojan, 2014-04-11 23:55:16]

I'm not super happy with this fixed, but I'm not really sure how else to address
it.

[esprehn, 2014-04-11 23:58:26]

Lgtm, this sucks, but hopefully we can eventually make this part of the syst
sane.

Why do we call this at both the start and end of layout?

[ojan, 2014-04-12 00:12:13]

The CQ bit was checked by ojan@chromium.org

[commit-bot: I haz the power, 2014-04-12 00:12:32]

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

[ojan, 2014-04-12 00:17:01]

> Why do we call this at both the start and end of layout?

We call it when you call setForcedCompositingMode on settings and then again
after layout. If you call setForcedCompositingMode and the RenderView doesn't
need layout, then we need to update this bit.

Once we've gotten rid of the chicken-egg bugs and the incremental compositing
updates, we could change setForcedCompositingMode to set a bit on
RenderLayerCompositor that it needs to update the m_forcedCompositing bit and
then do the update as part of the regular compositing update.

[commit-bot: I haz the power, 2014-04-12 00:51:37]

Change committed as 171389