WebGL: Free temporary GPU resources held by inactive or hidden WebGL.

WebGL: Free temporary GPU resources held by inactive or hidden WebGL.

This CL applies Canvas 2D change in r165966 to WebGL

TEST=fast/canvas/webgl/webgl-composite-modes-tabswitching.html,
DrawingBufferTest.verifySetIsHiddenProperlyAffectsMailboxes

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

[dshwang, 2014-04-26 18:25:04]

It's kind of follow-up CL for junov's 2D Canvas improvement;
https://codereview.chromium.org/117703004

[dshwang, 2014-04-26 18:25:54]

This CL is blocked by https://codereview.chromium.org/253663002/

[dshwang, 2014-04-27 12:46:16]

On 2014/04/26 18:25:54, dshwang wrote:
> This CL is blocked by https://codereview.chromium.org/253663002/

Above CL was landed.

[Justin Novosad, 2014-04-28 15:21:42]

https://codereview.chromium.org/251023004/diff/20001/Source/core/html/canvas/...
File Source/core/html/canvas/WebGLRenderingContextBase.h (right):

https://codereview.chromium.org/251023004/diff/20001/Source/core/html/canvas/...
Source/core/html/canvas/WebGLRenderingContextBase.h:364: virtual bool is3d()
const OVERRIDE { return true; }
These are public in the base class. Making the protected here is confusing.

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:198: freeRecycledMailboxes();
This is a good start. Eventually we should experiment with freeing even more.
Perhaps even evict the entire context and restore it when the pages becomes
visible again.

[Ken Russell (switch to Gerrit), 2014-04-28 20:51:45]

Thanks for this contribution. One significant question.

https://codereview.chromium.org/251023004/diff/20001/Source/core/html/canvas/...
File Source/core/html/canvas/WebGLRenderingContextBase.h (right):

https://codereview.chromium.org/251023004/diff/20001/Source/core/html/canvas/...
Source/core/html/canvas/WebGLRenderingContextBase.h:364: virtual bool is3d()
const OVERRIDE { return true; }
On 2014/04/28 15:21:42, junov wrote:
> These are public in the base class. Making the protected here is confusing.

Actually, it was a common pattern in WebKit, anyway, to make the implementations
of base class methods private. This movement seems OK to me. I think they could
actually be made private instead of protected.

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:189: void
DrawingBuffer::setIsHidden(bool hidden)
What happens when the DrawingBuffer is un-hidden? Will the page redraw
correctly? Is there a test verifying this case?

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:198: freeRecycledMailboxes();
On 2014/04/28 15:21:42, junov wrote:
> This is a good start. Eventually we should experiment with freeing even more.
> Perhaps even evict the entire context and restore it when the pages becomes
> visible again.

zmo@ is actively working on deciding when to evict WebGL contexts, and which
contexts to evict. Let's not collide or duplicate work in this area.

[dshwang, 2014-04-29 16:07:03]

Thank you for review.

https://codereview.chromium.org/251023004/diff/20001/Source/core/html/canvas/...
File Source/core/html/canvas/WebGLRenderingContextBase.h (right):

https://codereview.chromium.org/251023004/diff/20001/Source/core/html/canvas/...
Source/core/html/canvas/WebGLRenderingContextBase.h:364: virtual bool is3d()
const OVERRIDE { return true; }
I wanted to put them in private:, but there is not "private:" in this class.

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:189: void
DrawingBuffer::setIsHidden(bool hidden)
On 2014/04/28 20:51:45, Ken Russell wrote:
> What happens when the DrawingBuffer is un-hidden? Will the page redraw
> correctly? Is there a test verifying this case?

When un-hidden, DrawingBuffer recreate mailbox for compositor in
prepareMailbox().

That's good concern. I'll make a layout test. It would be pixel test after
hidden and unhidden.

https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:198: freeRecycledMailboxes();
On 2014/04/28 20:51:45, Ken Russell wrote:
> On 2014/04/28 15:21:42, junov wrote:
> > This is a good start. Eventually we should experiment with freeing even
more.
> > Perhaps even evict the entire context and restore it when the pages becomes
> > visible again.
> 
> zmo@ is actively working on deciding when to evict WebGL contexts, and which
> contexts to evict. Let's not collide or duplicate work in this area.

IMO, it's not overlapped with evicting contexts. This CL just removes temporary
mailboxs (= textures), when page is hidden. zmo@, wdyt?

[Ken Russell (switch to Gerrit), 2014-04-29 20:48:07]

FYI: until the flakiness associated with recent DrawingBuffer and related
changes has been fixed -- see http://crbug.com/365904 -- I do not support making
any non-essential and non-bug-fix changes to this code.

[dshwang, 2014-07-04 09:45:35]

On 2014/04/29 20:48:07, Ken Russell wrote:
> FYI: until the flakiness associated with recent DrawingBuffer and related
> changes has been fixed -- see http://crbug.com/365904 -- I do not support
making
> any non-essential and non-bug-fix changes to this code.

Hi, I rebase to ToT. As GPU flakiness was resolved, imo this CL can be reviewed.
Could you review?
This CL is not non-essential. When user switch another tab, this CL save vram
immediately by few megabyte; e.g. the size of 1024x1024 webgl's temporary
texture is 4MB.
In Ubercomp case, WebGL usually uses 2 temporary textures. Window, Linux, and
Cros uses can save huge vram immediately.


On 2014/04/29 16:07:03, dshwang wrote:
>
https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
> File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):
> 
>
https://codereview.chromium.org/251023004/diff/20001/Source/platform/graphics...
> Source/platform/graphics/gpu/DrawingBuffer.cpp:189: void
> DrawingBuffer::setIsHidden(bool hidden)
> On 2014/04/28 20:51:45, Ken Russell wrote:
> > What happens when the DrawingBuffer is un-hidden? Will the page redraw
> > correctly? Is there a test verifying this case?
> 
> When un-hidden, DrawingBuffer recreate mailbox for compositor in
> prepareMailbox().
> 
> That's good concern. I'll make a layout test. It would be pixel test after
> hidden and unhidden.

I added a layout test to check if WebGL renders well after user switches tab to
invisible and then to visible.

[Ken Russell (switch to Gerrit), 2014-07-08 23:18:24]

LGTM. Thanks for working on this. One minor comment.

https://codereview.chromium.org/251023004/diff/40001/LayoutTests/fast/canvas/...
File LayoutTests/fast/canvas/webgl/webgl-composite-modes-tabswitching.html
(right):

https://codereview.chromium.org/251023004/diff/40001/LayoutTests/fast/canvas/...
LayoutTests/fast/canvas/webgl/webgl-composite-modes-tabswitching.html:125:
function SetPageVisible() {
Please use consistent capitalization: setPageVisible.

[dshwang, 2014-07-09 06:59:56]

On 2014/07/08 23:18:24, Ken Russell wrote:
> LGTM. Thanks for working on this. One minor comment.

Thank you for reviewing!


>
https://codereview.chromium.org/251023004/diff/40001/LayoutTests/fast/canvas/...
> File LayoutTests/fast/canvas/webgl/webgl-composite-modes-tabswitching.html
> (right):
> 
>
https://codereview.chromium.org/251023004/diff/40001/LayoutTests/fast/canvas/...
> LayoutTests/fast/canvas/webgl/webgl-composite-modes-tabswitching.html:125:
> function SetPageVisible() {
> Please use consistent capitalization: setPageVisible.

DONE.

[dshwang, 2014-07-09 07:00:00]

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

[commit-bot: I haz the power, 2014-07-09 07:00:34]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/251023004/60001

[commit-bot: I haz the power, 2014-07-09 10:05:00]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/16019)

[commit-bot: I haz the power, 2014-07-09 10:41:12]

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

[commit-bot: I haz the power, 2014-07-09 10:41:15]

Try jobs failed on following builders:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/16019)

[dshwang, 2014-07-09 12:27:16]

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

[commit-bot: I haz the power, 2014-07-09 12:28:16]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/251023004/60001

[commit-bot: I haz the power, 2014-07-09 13:32:53]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/16053)

[commit-bot: I haz the power, 2014-07-09 14:41:04]

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

[commit-bot: I haz the power, 2014-07-09 14:41:06]

Try jobs failed on following builders:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/16062)

[dshwang, 2014-07-09 15:13:27]

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

[dshwang, 2014-07-09 15:14:40]

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

[dshwang, 2014-07-09 15:18:25]

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

[commit-bot: I haz the power, 2014-07-09 15:19:25]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/251023004/80001

[danakj, 2014-07-09 15:27:28]

Some drive-by follow up thoughts for you.

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:199: freeRecycledMailboxes();
Have you considered sending the renderer compositor an empty frame to let it
release its resource back to you if the browser evicts the frame also?

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:218: if (!m_contentsChanged ||
m_isHidden)
Does this ever happen? The compositor never produces frames while hidden.

[dshwang, 2014-07-09 15:56:01]

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

[dshwang, 2014-07-09 16:04:29]

Thank you for comment.

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:199: freeRecycledMailboxes();
I've not considered yet.
Currently, WebGL can release resource after resource_provider calls release
callback of external resource.
Do you mean that it might be better to create some pulling mechanism to make
WebGL take resources from compositor synchronously?
Could you explain more what you're worry about?

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:218: if (!m_contentsChanged ||
m_isHidden)
That's good point. I think so. Let me check.

[danakj, 2014-07-09 16:08:48]

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:199: freeRecycledMailboxes();
On 2014/07/09 16:04:29, dshwang wrote:
> I've not considered yet.
> Currently, WebGL can release resource after resource_provider calls release
> callback of external resource.
> Do you mean that it might be better to create some pulling mechanism to make
> WebGL take resources from compositor synchronously?
> Could you explain more what you're worry about?

I mean if WebGL goes invisible the renderer compositor still has the last
mailbox given to it. I was thinking if you give cc an empty mailbox then it can
release the ref held on it by the renderer compositor.

BUT, cc stops doing commits and stuff while not visible, so actually that won't
work. cc would have to initiate the release when it goes invisible in
LTHI::SetVisible
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...
but I don't think it does for any external resources right now. So that's def
outside the scope of this CL. :)

[Ken Russell (switch to Gerrit), 2014-07-09 17:27:17]

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
Source/platform/graphics/gpu/DrawingBuffer.cpp:199: freeRecycledMailboxes();
On 2014/07/09 16:08:48, danakj wrote:
> On 2014/07/09 16:04:29, dshwang wrote:
> > I've not considered yet.
> > Currently, WebGL can release resource after resource_provider calls release
> > callback of external resource.
> > Do you mean that it might be better to create some pulling mechanism to make
> > WebGL take resources from compositor synchronously?
> > Could you explain more what you're worry about?
> 
> I mean if WebGL goes invisible the renderer compositor still has the last
> mailbox given to it. I was thinking if you give cc an empty mailbox then it
can
> release the ref held on it by the renderer compositor.
> 
> BUT, cc stops doing commits and stuff while not visible, so actually that
won't
> work. cc would have to initiate the release when it goes invisible in
> LTHI::SetVisible
>
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...
> but I don't think it does for any external resources right now. So that's def
> outside the scope of this CL. :)

If the compositor releases its reference to the last produced mailbox and then
the tab is brought to the foreground without the app redrawing the WebGL canvas,
what will happen? Will the compositor still be able to draw the most recently
produced output from the canvas? This is also needed for printing.

[dshwang, 2014-07-09 17:36:08]

On 2014/07/09 16:08:48, danakj wrote:
>
https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
> File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):
> 
>
https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
> Source/platform/graphics/gpu/DrawingBuffer.cpp:199: freeRecycledMailboxes();
> I mean if WebGL goes invisible the renderer compositor still has the last
> mailbox given to it. I was thinking if you give cc an empty mailbox then it
can
> release the ref held on it by the renderer compositor.
> 
> BUT, cc stops doing commits and stuff while not visible, so actually that
won't
> work. cc would have to initiate the release when it goes invisible in
> LTHI::SetVisible
>
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...
> but I don't think it does for any external resources right now. So that's def
> outside the scope of this CL. :)

Thank you for deep explanation.
In addition, if setting hidden in main thread and compositor draws webgl texture
in impl thread simultaneously, compositor returns the last texture to WebGL and
WebGL deletes the texture in mailboxReleased().


On 2014/07/09 15:27:28, danakj wrote:
>
https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
> Source/platform/graphics/gpu/DrawingBuffer.cpp:218: if (!m_contentsChanged ||
> m_isHidden)
> Does this ever happen? The compositor never produces frames while hidden.

You are right. It never happens.
ThreadProxy::BeginMainFrame() returns early on main thread if hidden. So
BeginMainFrame() cannot call layer_tree_host()->UpdateLayers() and then
DrawingBuffer::prepareMailbox().

void ThreadProxy::BeginMainFrame(
    scoped_ptr<BeginMainFrameAndCommitState> begin_main_frame_state) {
  ...
  if (!layer_tree_host()->visible()) {
    TRACE_EVENT_INSTANT0("cc", "EarlyOut_NotVisible", TRACE_EVENT_SCOPE_THREAD);
    bool did_handle = false;
    Proxy::ImplThreadTaskRunner()->PostTask(
        FROM_HERE,
        base::Bind(&ThreadProxy::BeginMainFrameAbortedOnImplThread,
                   impl_thread_weak_ptr_,
                   did_handle));
    return;
  }
  ...
  bool updated = layer_tree_host()->UpdateLayers(queue.get());
  ...
}

[dshwang, 2014-07-09 17:40:54]

kbr@, I changes code a bit. Could you review again? I commented why I changed.

https://codereview.chromium.org/251023004/diff/100001/Source/platform/graphic...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/100001/Source/platform/graphic...
Source/platform/graphics/gpu/DrawingBuffer.cpp:195: m_isHidden = hidden;
I changes m_isHidden meaning. It doesn't include m_destructionInProgress
anymore. m_isHidden is used in two places. If m_destructionInProgress should be
checked, I check it explicitly.

https://codereview.chromium.org/251023004/diff/100001/Source/platform/graphic...
Source/platform/graphics/gpu/DrawingBuffer.cpp:216: ASSERT(!m_isHidden);
As danakj@ mentioned, 'm_isHidden == true' never happens here.

https://codereview.chromium.org/251023004/diff/100001/Source/platform/graphic...
File Source/platform/graphics/gpu/DrawingBufferTest.cpp (right):

https://codereview.chromium.org/251023004/diff/100001/Source/platform/graphic...
Source/platform/graphics/gpu/DrawingBufferTest.cpp:637: 
Remove EXPECT_FALSE(m_drawingBuffer->prepareMailbox(&mailbox, 0)); because I add
ASSERT in prepareMailbox()

[dshwang, 2014-07-09 17:45:38]

On 2014/07/09 17:27:17, Ken Russell wrote:
>
https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
> File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):
> 
>
https://codereview.chromium.org/251023004/diff/80001/Source/platform/graphics...
> Source/platform/graphics/gpu/DrawingBuffer.cpp:199: freeRecycledMailboxes();
> On 2014/07/09 16:08:48, danakj wrote:
> > On 2014/07/09 16:04:29, dshwang wrote:
> > > I've not considered yet.
> > > Currently, WebGL can release resource after resource_provider calls
release
> > > callback of external resource.
> > > Do you mean that it might be better to create some pulling mechanism to
make
> > > WebGL take resources from compositor synchronously?
> > > Could you explain more what you're worry about?
> > 
> > I mean if WebGL goes invisible the renderer compositor still has the last
> > mailbox given to it. I was thinking if you give cc an empty mailbox then it
> can
> > release the ref held on it by the renderer compositor.
> > 
> > BUT, cc stops doing commits and stuff while not visible, so actually that
> won't
> > work. cc would have to initiate the release when it goes invisible in
> > LTHI::SetVisible
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...
> > but I don't think it does for any external resources right now. So that's
def
> > outside the scope of this CL. :)
> 
> If the compositor releases its reference to the last produced mailbox and then
> the tab is brought to the foreground without the app redrawing the WebGL
canvas,
> what will happen? Will the compositor still be able to draw the most recently
> produced output from the canvas? This is also needed for printing.

That's good question. This CL removes the only mailbox that is returned.
If browser compositor doesn't reclaim the webgl mailbox to render compositor,
webgl doesn't remove it, because it isn't returned. So browser compositor can
draw it again as-is.

[danakj, 2014-07-09 17:55:17]

On Wed, Jul 9, 2014 at 1:27 PM, <kbr@chromium.org> wrote:

>
> https://codereview.chromium.org/251023004/diff/80001/
> Source/platform/graphics/gpu/DrawingBuffer.cpp
> File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):
>
> https://codereview.chromium.org/251023004/diff/80001/
> Source/platform/graphics/gpu/DrawingBuffer.cpp#newcode199
> Source/platform/graphics/gpu/DrawingBuffer.cpp:199:
> freeRecycledMailboxes();
> On 2014/07/09 16:08:48, danakj wrote:
>
>> On 2014/07/09 16:04:29, dshwang wrote:
>> > I've not considered yet.
>> > Currently, WebGL can release resource after resource_provider calls
>>
> release
>
>> > callback of external resource.
>> > Do you mean that it might be better to create some pulling mechanism
>>
> to make
>
>> > WebGL take resources from compositor synchronously?
>> > Could you explain more what you're worry about?
>>
>
>  I mean if WebGL goes invisible the renderer compositor still has the
>>
> last
>
>> mailbox given to it. I was thinking if you give cc an empty mailbox
>>
> then it can
>
>> release the ref held on it by the renderer compositor.
>>
>
>  BUT, cc stops doing commits and stuff while not visible, so actually
>>
> that won't
>
>> work. cc would have to initiate the release when it goes invisible in
>> LTHI::SetVisible
>>
>
> https://code.google.com/p/chromium/codesearch#chromium/
> src/cc/trees/layer_tree_host_impl.cc&rcl=1404816569&l=1766
>
>> but I don't think it does for any external resources right now. So
>>
> that's def
>
>> outside the scope of this CL. :)
>>
>
> If the compositor releases its reference to the last produced mailbox
> and then the tab is brought to the foreground without the app redrawing
> the WebGL canvas, what will happen? Will the compositor still be able to
> draw the most recently produced output from the canvas? This is also
> needed for printing.
>

The compositor releases all of its own resources when becoming invisible
but not webgl. When it becomes visible again, it waits for its own
resources to be recreated, but it would need to do a commit and wait for
that before drawing to collect the webgl resources again. I don't think
this logic exists today, since we don't drop the resources anyway.

We've talked about this situation when a context is lost/recovered, making
the compositor wait until each external resource has been updated. It would
be a similar thing when going invisible/visible.

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[Ken Russell (switch to Gerrit), 2014-07-09 20:57:57]

Looks nice. LGTM

https://codereview.chromium.org/251023004/diff/100001/Source/platform/graphic...
File Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/251023004/diff/100001/Source/platform/graphic...
Source/platform/graphics/gpu/DrawingBuffer.cpp:192:
ASSERT(!m_destructionInProgress);
This assert seems a little aggressive, but I do agree after re-reading
WebGLRenderingContextBase that it should never happen.

[dshwang, 2014-07-10 12:17:33]

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

[commit-bot: I haz the power, 2014-07-10 12:18:02]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/251023004/10...

[commit-bot: I haz the power, 2014-07-10 13:18:29]

Change committed as 177827

[Justin Novosad, 2014-07-10 17:10:53]

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

The reason for reverting is: The following tests have become flaky after this
change was committed:
ContextLost.WebGLContextLostFromGPUProcessExit 
WebglConformance.conformance_context_incorrect_context_object_behaviour

The flakiness was observed in debug builds on Win7 and Linux

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40...

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40....

[dshwang, 2014-07-10 19:52:58]

Thank you for reporting. I'll investigate.