Fix RAF-stall that occurs when switching between WebGL animation and another tab.

Fix RAF-stall that occurs when switching between WebGL animation and another tab. For some reason the RAF engine will stall permanently when switching back to a WebGL animation when the early out code is there. This just allows a DoDeferredUpdate anyway, which should be harmless because the visible check is done later.

BUG=85265
TEST=switch between WebGL particles demo and about:flags for a while, notice no stall.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=88474

[nduca, 2011-06-08 00:26:48]

Can you help me understand what the race condition is that triggers this? I
don't doubt you've found something here... but I'd like to understand what is
going wrong here.

[jbates, 2011-06-08 01:01:05]

On 2011/06/08 00:26:48, nduca wrote:
> Can you help me understand what the race condition is that triggers this? I
> don't doubt you've found something here... but I'd like to understand what is
> going wrong here.

When the WebGL tab goes from hidden to visible, it renders one frame via
WebViewImpl::composite, and on the SwapBuffers ack it triggers
EarlyOut_ZeroSwapbuffersPending. I'm not sure why, but I will attach the trace
to the bug. Btw, what's the purpose of EarlyOut_ZeroSwapbuffersPending? If there
are other earlyouts later in DoDeferredUpdate, why bother here? Will this change
cause any other issues?

[nduca, 2011-06-08 01:24:25]

Hmm, so the zero swapbuffers pending case is supposed to occur only when the
context is lost (swapbuffersAborted). I think there's something funky going on
here... are we losing the context here? I assume not... if not, how are we
getting to zero?

I'd be curious if didActivateAcceleratedCompositing was getting called when
rotating tabs. It shouldn't be, but that sets a flag saying "not swapping
asynchronously"...

[jbates, 2011-06-08 16:35:46]

On 2011/06/08 01:24:25, nduca wrote:
> Hmm, so the zero swapbuffers pending case is supposed to occur only when the
> context is lost (swapbuffersAborted). I think there's something funky going on
> here... are we losing the context here? I assume not... if not, how are we
> getting to zero?
> 
> I'd be curious if didActivateAcceleratedCompositing was getting called when
> rotating tabs. It shouldn't be, but that sets a flag saying "not swapping
> asynchronously"...

With this change, the stall does not occur in my tests, so if it's safe let me
know and I'll commit.

If you'd like me to investigate further, perhaps you could help me understand
the purpose of EarlyOut_ZeroSwapbuffersPending. If there are other earlyouts
later in DoDeferredUpdate, why bother here?

[nduca, 2011-06-08 16:50:36]

The purpose of the early out is for a specific lost-context case. It should
never happen in regular operation. I'm seeing it get hit when switchings tabs
--- I'm wondering why that's happening, since it seems to me that should never
happen. I.e. is there some other underlying thing that needs fixing here.

[jbates, 2011-06-08 23:41:44]

Fixed the root cause, passes basic testing.

[nduca, 2011-06-08 23:43:18]

LGTM

[jamesr, 2011-06-08 23:44:38]

lgtm