WebGL: Refactor active context management.

WebGL: Refactor active context management.

This CL makes WebGL lost&retore code more succinct.

1. Deactive a context in loseContextImpl(), instead of dispatchContextLostEvent().
Because of
a) Prevent inconsistent state. Currently, activeContext() vector can store a lost
context due to this, so oldestContextIndex() needs to check if active context is
lost. Now we don't need redundant lostContext check. In addition, it does not
make sense that active context list can store a lost context.
b) In the same sense, only maybeRestoreContext() actives a context like loseContextImpl()
in this CL.

2. Don't call activeContexts().remove() adhoc.
Only deactiveContext() calls activeContexts().remove() like only activeContext()
calls activeContexts().append().

3. Change the logic of dispatchContextLostEvent().
Currently, when m_contextLostMode != RealLostContext, a context is added to
forcibly evicted list, in which the context will be restored when another
context is destructed. However, we start the restore-timer when
the context is lost due to AutoRecoverSyntheticLostContext also. It means
AutoRecoverSyntheticLostContext can restore twice. So this CL changes a context
to be added into forcibly evicted list only if SyntheticLostContext.

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

[dshwang, 2014-04-24 08:25:56]

I clean up some messy logic.
Could you review?

[bajones, 2014-04-24 18:09:40]

On 2014/04/24 08:25:56, dshwang wrote:
> I clean up some messy logic.
> Could you review?

This looks like a good clean up, thanks! The only thing I would caution against
is that this area of the code has proven to be easy to break in subtle ways
(hopefully this CL improves that) so testing is critical.

Non-owners LGTM as long as this has been thoroughly tested.

[dshwang, 2014-04-24 18:45:50]

On 2014/04/24 18:09:40, bajones wrote:
> On 2014/04/24 08:25:56, dshwang wrote:
> > I clean up some messy logic.
> > Could you review?
> 
> This looks like a good clean up, thanks! The only thing I would caution
against
> is that this area of the code has proven to be easy to break in subtle ways
> (hopefully this CL improves that) so testing is critical.
> 
> Non-owners LGTM as long as this has been thoroughly tested.

Thank you for review.

I agree. I'll rethink how to test, as well as wait for few days to observe gpu
bots because recently webgl code has been changed much.

[Ken Russell (switch to Gerrit), 2014-05-02 23:04:19]

Sorry for the holdup on reviewing this, but we are still investigating flakiness
of the context lost tests in http://crbug.com/365904 and until all of those
issues are resolved I don't support making any changes in this area.

Any help reproducing and fixing the issues would be welcome. I can reproduce
issues on debug Mac builds, FYI.

[dshwang, 2014-06-02 14:40:52]

Hi, could you re-review because flakiness was fixed?

Speaking test, #1 and #2 preserve the logic. IMO, webgl conformance test and gpu
lost-context test covers them well.
#3 changes the logic for AutoRecoverSyntheticLostContext, which only Mac uses
when msaa is switching; crrev.com/14840015
This code is called when following code is called;
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/gp...
It looks difficult to make a test for it.

[Ken Russell (switch to Gerrit), 2014-07-08 21:01:03]

I apologize for the long delay, but until the root cause of Issue 374086 was
just recently fixed, we weren't prepared to make more changes in this area.

I just filed Issue 392274 and pointed this CL at it, because the two bugs this
was previously pointing to are already marked fixed, and more CLs should not be
attributed to them.

Overall, this CL looks good, but at this point it must be rebased. Could you
please do this, and send the CL to the try servers again? More tests have
recently been added around the context's lifecycle, which should help uncover
any issues with the patch.

[dshwang, 2014-07-09 07:55:21]

On 2014/07/08 21:01:03, Ken Russell wrote:
> I apologize for the long delay, but until the root cause of Issue 374086 was
> just recently fixed, we weren't prepared to make more changes in this area.

I didn't know about tab crashing issue. I wanna contribute if possible.

> I just filed Issue 392274 and pointed this CL at it, because the two bugs this
> was previously pointing to are already marked fixed, and more CLs should not
be
> attributed to them.

Thank you for creating new issue!

> Overall, this CL looks good, but at this point it must be rebased. Could you
> please do this, and send the CL to the try servers again? More tests have
> recently been added around the context's lifecycle, which should help uncover
> any issues with the patch.

Thank you for kind explanation. Done.

[Ken Russell (switch to Gerrit), 2014-07-09 21:34:46]

Thanks. This improves the understandability of the code. LGTM

[dshwang, 2014-07-10 13:32:10]

The CQ bit was checked by dongseong.hwang@intel.com

[commit-bot: I haz the power, 2014-07-10 13:33:50]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/251373005/40001

[commit-bot: I haz the power, 2014-07-10 14:09:49]

Change committed as 177833

[ccameron, 2014-07-10 19:13:36]

On 2014/07/10 14:09:49, I haz the power (commit-bot) wrote:
> Change committed as 177833

I think this is causing a failure at:
http://build.chromium.org/p/chromium.gpu/builders/Mac%20Debug%20%28Intel%29/b...

[Ken Russell (switch to Gerrit), 2014-07-10 19:20:35]

On 2014/07/10 19:13:36, ccameron1 wrote:
> On 2014/07/10 14:09:49, I haz the power (commit-bot) wrote:
> > Change committed as 177833
> 
> I think this is causing a failure at:
>
http://build.chromium.org/p/chromium.gpu/builders/Mac%20Debug%20%28Intel%29/b...

Yes, it is. I reverted it in
http://src.chromium.org/viewvc/blink?view=rev&rev=177871 .

[ccameron, 2014-07-10 19:26:15]

A revert of this CL has been created in
https://codereview.chromium.org/388573004/ by ccameron@chromium.org.

The reason for reverting is: This is likely to be the cause of crashes observed
in
http://build.chromium.org/p/chromium.gpu/builders/Mac%20Debug%20%28Intel%29/b....