gpu: Remove WebGraphicsContext3D::makeContextCurrent()

gpu: Remove WebGraphicsContext3D::makeContextCurrent()

We don't need to call it before using GL context anymore.

BUG=404121
Committed: https://crrev.com/3ed758c9a46ec8579cc3a5cb2955161a8a322f0b
Cr-Commit-Position: refs/heads/master@{#292592}

[dshwang, 2014-08-14 12:37:26]

Could you review?

There are clients of RenderThreadImpl::SharedMainThreadContextProvider() which
expect the context 3D already makes current. e.g.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

RenderThreadImpl::SharedMainThreadContextProvider() calls
ContextProvider::BindToCurrentThread every time to satisfy clients. However,
only first BindToCurrentThread() call actually executes
WebGraphicsContext3D::makeContextCurrent(). So this CL changes
ContextProvider::BindToCurrentThread always calls makeContextCurrent().

Client can call makeContextCurrent() every time, but the API looks
not-intuitive.
Those clients want to use GrContext via
RenderThreadImpl::SharedMainThreadContextProvider().
If they must call makeContextCurrent(), code looks like
m_contextProvider =
adoptPtr(blink::Platform::current()->createSharedOffscreenGraphicsContext3DProvider());
m_contextProvider->context3D()->makeContextCurrent();
GrContext* gr = m_contextProvider->grContext();
They must call WebGraphicsContext3D API to use GrContext although they don't
need WebGraphicsContext3D at all. It's confusing.

So I decide RenderThreadImpl::SharedMainThreadContextProvider() makes current
internally.

[danakj, 2014-08-14 16:41:24]

Hm.. I don't think I agree with the change. My understanding is that our context
code always makes itself current when you do any command on it.

I guess this isn't happening in some context, but what you've put in the
ContextProvider comment would be wrong for how I understand people using the
context inside it.

[danakj, 2014-08-14 16:44:39]

In cc/ when we want to use the GrContext, we use this
https://code.google.com/p/chromium/codesearch#chromium/src/cc/output/gl_rende...
.

Perhaps resetContext makes the context current for us. Or perhaps we've
already used the WGC3D at that point so it's already current? Maybe you
need something similar where you make current when you want to use the
GrContext?


On Thu, Aug 14, 2014 at 12:41 PM, <danakj@chromium.org> wrote:

> Hm.. I don't think I agree with the change. My understanding is that our
> context
> code always makes itself current when you do any command on it.
>
> I guess this isn't happening in some context, but what you've put in the
> ContextProvider comment would be wrong for how I understand people using
> the
> context inside it.
>
> https://codereview.chromium.org/470973002/
>

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

[danakj, 2014-08-14 16:52:53]

Or maybe the skia GrContext needs to make the context current.

[danakj, 2014-08-14 16:53:07]

(You should probably file a bug for this)

[jamesr, 2014-08-14 18:01:13]

lbtm.  The C++ bindings do not require setting the context in TLS and everything
that uses these contexts should be using those bindings.

[dshwang, 2014-08-14 18:46:31]

On 2014/08/14 18:01:13, jamesr wrote:
> lbtm.  The C++ bindings do not require setting the context in TLS and
everything
> that uses these contexts should be using those bindings.

Thanks for quick opinion. I want to say objection.

GrContext doesn't not refer to GLInterface pointer or WebGraphicsContext3D
pointer.
Look at binding code for GrContext;
https://code.google.com/p/chromium/codesearch#chromium/src/gpu/skia_bindings/...
Chromium just inform GrContext to function pointer.
When the given function pointer is called, it goes to TLS and calls
WebGraphicsContext3D's method.

It's why we cannot acheive it by just adding makeCurrent to GrContext. GrContext
don't know what is proper WebGraphicsContext3D pointer that it should use. So
WebGraphicsContext3D or ContextProvider should update TLS before using
GrContext.

[danakj, 2014-08-14 18:52:37]

On Thu, Aug 14, 2014 at 2:46 PM, <dongseong.hwang@intel.com> wrote:

> On 2014/08/14 18:01:13, jamesr wrote:
>
>> lbtm.  The C++ bindings do not require setting the context in TLS and
>>
> everything
>
>> that uses these contexts should be using those bindings.
>>
>
> Thanks for quick opinion. I want to say objection.
>
> GrContext doesn't not refer to GLInterface pointer or WebGraphicsContext3D
> pointer.
> Look at binding code for GrContext;
> https://code.google.com/p/chromium/codesearch#chromium/
> src/gpu/skia_bindings/gl_bindings_skia_cmd_buffer.cc&
> rcl=1407928291&l=17&type=cs&sq=package:chromium
> Chromium just inform GrContext to function pointer.
> When the given function pointer is called, it goes to TLS and calls
> WebGraphicsContext3D's method.
>
> It's why we cannot acheive it by just adding makeCurrent to GrContext.
> GrContext
> don't know what is proper WebGraphicsContext3D pointer that it should use.
> So
> WebGraphicsContext3D or ContextProvider should update TLS before using
> GrContext.
>

It would be possible to call GrContext() and store the context pointer, so
doing makeCurrent in GrContext() doesn't really guard. That's why I suggest
maybe something like ScopedUseGrContext that cc uses.

Why can't the GrContext just have a makeCurrent function pointer too?

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

[dshwang, 2014-08-14 19:36:06]

On 2014/08/14 18:52:37, danakj wrote:
> On Thu, Aug 14, 2014 at 2:46 PM, <mailto:dongseong.hwang@intel.com> wrote:
> 
> > On 2014/08/14 18:01:13, jamesr wrote:
> >
> >> lbtm.  The C++ bindings do not require setting the context in TLS and
> >>
> > everything
> >
> >> that uses these contexts should be using those bindings.
> >>
> >
> > Thanks for quick opinion. I want to say objection.
> >
> > GrContext doesn't not refer to GLInterface pointer or WebGraphicsContext3D
> > pointer.
> > Look at binding code for GrContext;
> > https://code.google.com/p/chromium/codesearch#chromium/
> > src/gpu/skia_bindings/gl_bindings_skia_cmd_buffer.cc&
> > rcl=1407928291&l=17&type=cs&sq=package:chromium
> > Chromium just inform GrContext to function pointer.
> > When the given function pointer is called, it goes to TLS and calls
> > WebGraphicsContext3D's method.
> >
> > It's why we cannot acheive it by just adding makeCurrent to GrContext.
> > GrContext
> > don't know what is proper WebGraphicsContext3D pointer that it should use.
> > So
> > WebGraphicsContext3D or ContextProvider should update TLS before using
> > GrContext.
> >
> 
> It would be possible to call GrContext() and store the context pointer, so
> doing makeCurrent in GrContext() doesn't really guard. That's why I suggest
> maybe something like ScopedUseGrContext that cc uses.
> 
> Why can't the GrContext just have a makeCurrent function pointer too?
> 

Even if GrContext has a makeCurrent function pointer, somebody needs to change
TLS before calling it, doesn't it?

[jamesr, 2014-08-14 19:36:19]

There's no need to have a make current anywhere unless some system is using the
C bindings to talk to gpu::gles2::GLES2Interface.  The GrContext bindings are
using the C++ bindings which don't need anything to be set in TLS to work.  We
only have the make current call there once to initialize the context.

[jamesr, 2014-08-14 19:37:36]

I don't understand why that class is going through the C entry points, it should
be talking to a GLES2Interface type.  Do we use the same bindings for multiple
grcontexts?

[dshwang, 2014-08-15 09:18:49]

On 2014/08/14 19:37:36, jamesr wrote:
> I don't understand why that class is going through the C entry points, it
should
> be talking to a GLES2Interface type.  Do we use the same bindings for multiple
> grcontexts?

I guess skia team decided c type binding for portability.

Sorry for misunderstanding previously. Skia GrContext already has kind of
makeCurrent as danakj@ suggested.
https://code.google.com/p/chromium/codesearch#chromium/src/webkit/common/gpu/...
Every API call of GLES2Interface calls makeContextCurrent first. So skia doesn't
need this change.

In addition, we always call makeContextCurrent() before using
WebGraphicsContext3D. It's not necessary. AFAIU, makeContextCurrent() exists
only for GrContext.

I close this CL, Thank you for your time.

[dshwang, 2014-08-15 13:47:59]

After re-thinking of your good comment, I reach to fact that
WebGraphicsContext3D::makeContextCurrent() legacy and not-needed anymore.
So I filed the BUG=404121 and change this CL's purpose; remove
WebGraphicsContext3D::makeContextCurrent()
After this CL, I'll remove WebGraphicsContext3D::makeContextCurrent() in Blink
at all.

[dshwang, 2014-08-15 14:54:01]

I added some comments to explain the changes.

https://codereview.chromium.org/470973002/diff/80001/content/renderer/render_...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/470973002/diff/80001/content/renderer/render_...
content/renderer/render_thread_impl.cc:1181:
!shared_main_thread_contexts_->BindToCurrentThread())
BindToCurrentThread() should be called one time when creating.

This method is used by Accelerated 2D Canvas. Chromium returns the context after
binding already.

https://codereview.chromium.org/470973002/diff/80001/content/renderer/rendere...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/470973002/diff/80001/content/renderer/rendere...
content/renderer/renderer_webkitplatformsupport_impl.cc:979: if (context &&
!context->BindToCurrentThread()) {
This method is used by WebGL. Now we return the context after binding like
Accelerated 2D Canvas. Now Blink doesn't need
WebGraphicsContext3D::makeContextCurrent() anymore.

https://codereview.chromium.org/470973002/diff/80001/webkit/common/gpu/grcont...
File webkit/common/gpu/grcontext_for_webgraphicscontext3d.cc (right):

https://codereview.chromium.org/470973002/diff/80001/webkit/common/gpu/grcont...
webkit/common/gpu/grcontext_for_webgraphicscontext3d.cc:19:
interface->fCallbackData)->GetGLInterface());
Now this file is only client that uses gles2::SetGLContext() except for
unittests. gles2::SetGLContext() exists only for skia.

[danakj, 2014-08-15 15:28:44]

I think this looks like a good change overall, curious what jamesr thinks.

https://codereview.chromium.org/470973002/diff/80001/content/browser/android/...
File content/browser/android/in_process/synchronous_compositor_factory_impl.cc
(right):

https://codereview.chromium.org/470973002/diff/80001/content/browser/android/...
content/browser/android/in_process/synchronous_compositor_factory_impl.cc:210:
webkit::gpu::WebGraphicsContext3DImpl*
Why the change in types from WGC3D to WGC3DImpl? This happened in a few places
in this CL.

https://codereview.chromium.org/470973002/diff/80001/content/renderer/render_...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/470973002/diff/80001/content/renderer/render_...
content/renderer/render_thread_impl.cc:1181:
!shared_main_thread_contexts_->BindToCurrentThread())
On 2014/08/15 14:54:01, dshwang wrote:
> BindToCurrentThread() should be called one time when creating.
> 
> This method is used by Accelerated 2D Canvas. Chromium returns the context
after
> binding already.

This seems like a separate change, can you do this change by itself?

https://codereview.chromium.org/470973002/diff/80001/content/renderer/rendere...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/470973002/diff/80001/content/renderer/rendere...
content/renderer/renderer_webkitplatformsupport_impl.cc:957:
webkit::gpu::WebGraphicsContext3DImpl* context = NULL;
use scoped_ptr

[dshwang, 2014-08-15 16:02:32]

Thank you for fast review.

https://codereview.chromium.org/470973002/diff/80001/content/browser/android/...
File content/browser/android/in_process/synchronous_compositor_factory_impl.cc
(right):

https://codereview.chromium.org/470973002/diff/80001/content/browser/android/...
content/browser/android/in_process/synchronous_compositor_factory_impl.cc:210:
webkit::gpu::WebGraphicsContext3DImpl*
On 2014/08/15 15:28:44, danakj wrote:
> Why the change in types from WGC3D to WGC3DImpl? This happened in a few places
> in this CL.

I add BindToCurrentThread in WebGraphicsContext3DImpl, not WebGraphicsContext3D
and RendererWebKitPlatformSupportImpl::createOffscreenGraphicsContext3D() needs
to call it.

https://codereview.chromium.org/470973002/diff/80001/content/renderer/render_...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/470973002/diff/80001/content/renderer/render_...
content/renderer/render_thread_impl.cc:1181:
!shared_main_thread_contexts_->BindToCurrentThread())
On 2014/08/15 15:28:44, danakj wrote:
> On 2014/08/15 14:54:01, dshwang wrote:
> > BindToCurrentThread() should be called one time when creating.
> > 
> > This method is used by Accelerated 2D Canvas. Chromium returns the context
> after
> > binding already.
> 
> This seems like a separate change, can you do this change by itself?

Ok, I'll separate it on another CL.

https://codereview.chromium.org/470973002/diff/80001/content/renderer/rendere...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/470973002/diff/80001/content/renderer/rendere...
content/renderer/renderer_webkitplatformsupport_impl.cc:957:
webkit::gpu::WebGraphicsContext3DImpl* context = NULL;
On 2014/08/15 15:28:44, danakj wrote:
> use scoped_ptr

yes, I'll update soon.

[piman, 2014-08-15 17:47:34]

There's still some explicit makeContextCurrent on the blink side, that are not
only for initialization purpose. Do we know that skia will properly make current
on its own in these cases? In that case we should remove them first.

https://codereview.chromium.org/470973002/diff/100001/content/common/gpu/clie...
File content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc
(right):

https://codereview.chromium.org/470973002/diff/100001/content/common/gpu/clie...
content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc:230:
g_gles2_initializer.Get();
If we move out the ::gles2::SetGLContext, then we should move out the
g_gles2_initializer, which is only there to ensure we initialize the TLS
pointer.

https://codereview.chromium.org/470973002/diff/100001/content/renderer/render...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/470973002/diff/100001/content/renderer/render...
content/renderer/renderer_webkitplatformsupport_impl.cc:979: if (context &&
!context->BindToCurrentThread()) {
Are contexts created by this API exclusively used on the main thread now?

https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
File webkit/common/gpu/webgraphicscontext3d_impl.h (right):

https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
webkit/common/gpu/webgraphicscontext3d_impl.h:54: virtual bool
BindToCurrentThread() = 0;
nit: There's no initialize() method any more. This does initialization, I think
we should call it as such... Initialize() or something. Maybe
InitializeOnCurrentThread() if we want to convey the thread constraints.

https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
File webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc
(right):

https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc:129:
g_gles2_initializer.Get();
Same comment here.

[dshwang, 2014-08-15 17:58:13]

On 2014/08/15 17:47:34, piman (OOO) wrote:
> There's still some explicit makeContextCurrent on the blink side, that are not
> only for initialization purpose. Do we know that skia will properly make
current
> on its own in these cases? In that case we should remove them first.

I submitted Blink side CL also; https://codereview.chromium.org/481433002/
My plan is that land this CL first and then land Blink CL. However, if you want
opposite direction, I'll do it.

>
https://codereview.chromium.org/470973002/diff/100001/content/common/gpu/clie...
> File content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc
> (right):
> 
>
https://codereview.chromium.org/470973002/diff/100001/content/common/gpu/clie...
> content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc:230:
> g_gles2_initializer.Get();
> If we move out the ::gles2::SetGLContext, then we should move out the
> g_gles2_initializer, which is only there to ensure we initialize the TLS
> pointer.

That's good point. I'll move it to grcontext_for_webgraphicscontext3d.cc and all
unittests.

> 
>
https://codereview.chromium.org/470973002/diff/100001/content/renderer/render...
> File content/renderer/renderer_webkitplatformsupport_impl.cc (right):
> 
>
https://codereview.chromium.org/470973002/diff/100001/content/renderer/render...
> content/renderer/renderer_webkitplatformsupport_impl.cc:979: if (context &&
> !context->BindToCurrentThread()) {
> Are contexts created by this API exclusively used on the main thread now?
> 
>
https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
> File webkit/common/gpu/webgraphicscontext3d_impl.h (right):
> 
>
https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
> webkit/common/gpu/webgraphicscontext3d_impl.h:54: virtual bool
> BindToCurrentThread() = 0;
> nit: There's no initialize() method any more. This does initialization, I
think
> we should call it as such... Initialize() or something. Maybe
> InitializeOnCurrentThread() if we want to convey the thread constraints.

I'll change to InitializeOnCurrentThread().

> 
>
https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
> File webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc
> (right):
> 
>
https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/webgr...
> webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc:129:
> g_gles2_initializer.Get();
> Same comment here.

Yep.

[piman, 2014-08-15 18:14:33]

On Fri, Aug 15, 2014 at 10:58 AM, <dongseong.hwang@intel.com> wrote:

> On 2014/08/15 17:47:34, piman (OOO) wrote:
>
>> There's still some explicit makeContextCurrent on the blink side, that
>> are not
>> only for initialization purpose. Do we know that skia will properly make
>>
> current
>
>> on its own in these cases? In that case we should remove them first.
>>
>
> I submitted Blink side CL also; https://codereview.chromium.org/481433002/
> My plan is that land this CL first and then land Blink CL. However, if you
> want
> opposite direction, I'll do it.



I want to make sure we can easily bisect potential problems back to the
right CL. This changes the behavior on the blink side, so that makes it
harder.
So I would do:
1- remove all makeContextCurrent on blink side, that are not needed for
creation (i.e. first-time makeContextCurrent), and make sure that rolls and
didn't regress.
2- this CL
3- remove remaining makeContextCurrent on blink side.


>
>
>
> https://codereview.chromium.org/470973002/diff/100001/
> content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc
>
>> File content/common/gpu/client/webgraphicscontext3d_command_
>> buffer_impl.cc
>> (right):
>>
>
>
> https://codereview.chromium.org/470973002/diff/100001/
> content/common/gpu/client/webgraphicscontext3d_command_
> buffer_impl.cc#newcode230
>
>> content/common/gpu/client/webgraphicscontext3d_command_
>> buffer_impl.cc:230:
>> g_gles2_initializer.Get();
>> If we move out the ::gles2::SetGLContext, then we should move out the
>> g_gles2_initializer, which is only there to ensure we initialize the TLS
>> pointer.
>>
>
> That's good point. I'll move it to grcontext_for_webgraphicscontext3d.cc
> and all
> unittests.
>
>
>
>
> https://codereview.chromium.org/470973002/diff/100001/
> content/renderer/renderer_webkitplatformsupport_impl.cc
>
>> File content/renderer/renderer_webkitplatformsupport_impl.cc (right):
>>
>
>
> https://codereview.chromium.org/470973002/diff/100001/
> content/renderer/renderer_webkitplatformsupport_impl.cc#newcode979
>
>> content/renderer/renderer_webkitplatformsupport_impl.cc:979: if (context
>> &&
>> !context->BindToCurrentThread()) {
>> Are contexts created by this API exclusively used on the main thread now?
>>
>
>
> https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/
> webgraphicscontext3d_impl.h
>
>> File webkit/common/gpu/webgraphicscontext3d_impl.h (right):
>>
>
>
> https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/
> webgraphicscontext3d_impl.h#newcode54
>
>> webkit/common/gpu/webgraphicscontext3d_impl.h:54: virtual bool
>> BindToCurrentThread() = 0;
>> nit: There's no initialize() method any more. This does initialization, I
>>
> think
>
>> we should call it as such... Initialize() or something. Maybe
>> InitializeOnCurrentThread() if we want to convey the thread constraints.
>>
>
> I'll change to InitializeOnCurrentThread().
>
>
>
>
> https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/
> webgraphicscontext3d_in_process_command_buffer_impl.cc
>
>> File webkit/common/gpu/webgraphicscontext3d_in_
>> process_command_buffer_impl.cc
>> (right):
>>
>
>
> https://codereview.chromium.org/470973002/diff/100001/webkit/common/gpu/
> webgraphicscontext3d_in_process_command_buffer_impl.cc#newcode129
>
>> webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.
>> cc:129:
>> g_gles2_initializer.Get();
>> Same comment here.
>>
>
> Yep.
>
> https://codereview.chromium.org/470973002/
>

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

[dshwang, 2014-08-15 18:51:11]

On 2014/08/15 18:14:33, piman (OOO) wrote:
> On Fri, Aug 15, 2014 at 10:58 AM, <mailto:dongseong.hwang@intel.com> wrote:
> I want to make sure we can easily bisect potential problems back to the
> right CL. This changes the behavior on the blink side, so that makes it
> harder.
> So I would do:
> 1- remove all makeContextCurrent on blink side, that are not needed for
> creation (i.e. first-time makeContextCurrent), and make sure that rolls and
> didn't regress.
> 2- this CL
> 3- remove remaining makeContextCurrent on blink side.
> 

Thank you for explaining proper step. Blink side CL needs to update to be landed
first. I'll do it soon.

[dshwang, 2014-08-28 13:47:27]

On 2014/08/15 18:51:11, dshwang wrote:
> On 2014/08/15 18:14:33, piman (OOO) wrote:
> > On Fri, Aug 15, 2014 at 10:58 AM, <mailto:dongseong.hwang@intel.com> wrote:
> > I want to make sure we can easily bisect potential problems back to the
> > right CL. This changes the behavior on the blink side, so that makes it
> > harder.
> > So I would do:
> > 1- remove all makeContextCurrent on blink side, that are not needed for
> > creation (i.e. first-time makeContextCurrent), and make sure that rolls and
> > didn't regress.
> > 2- this CL
> > 3- remove remaining makeContextCurrent on blink side.

#1 is done in https://codereview.chromium.org/481433002/
I update this CL to apply piman's comments in #msg17
Could you review?

Currently, build bots fail because Blink commit is not rolled yet.

[piman, 2014-08-28 18:13:02]

lgtm

https://codereview.chromium.org/470973002/diff/120001/content/renderer/render...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/470973002/diff/120001/content/renderer/render...
content/renderer/renderer_webkitplatformsupport_impl.cc:962: #endif
nit: this is a little hard to read (the interaction between the if and the #if).
How about:

#if defined(OS_ANDROID)
if (SynchronousCompositorFactory* factory = 
SynchronousCompositorFactory::GetInstance()) {
 context.reset(factory->CreateOffscreenGraphicsContext3D(attributes));
}
#endif

if (!context) {
  scoped_refptr<GpuChannelHost> gpu_channel_host(
    RenderThreadImpl::current()->EstablishGpuChannelSync(
      CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE));
  // [...]
}

[dshwang, 2014-08-29 07:06:35]

Thank you for review.

https://codereview.chromium.org/470973002/diff/140001/content/renderer/render...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/470973002/diff/140001/content/renderer/render...
content/renderer/renderer_webkitplatformsupport_impl.cc:957: bool
must_use_synchronous_factory = false;
Introduce this local variable, because Android webview must not call
RenderThreadImpl::current()->EstablishGpuChannelSync(...) although creation by
SynchronousCompositorFactory fails.

[dshwang, 2014-08-29 07:07:04]

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

[commit-bot: I haz the power, 2014-08-29 07:07:22]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/470973002/14...

[dshwang, 2014-08-29 07:40:36]

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

[dshwang, 2014-08-29 08:01:52]

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

[commit-bot: I haz the power, 2014-08-29 08:02:26]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/470973002/16...

[commit-bot: I haz the power, 2014-08-29 08:47:25]

Committed patchset #6 (id:160001) as c26ab7d39c0ba0792e1656f8918c625b3260273a

[commit-bot: I haz the power, 2014-09-10 03:07:04]

Patchset 6 (id:??) landed as
https://crrev.com/3ed758c9a46ec8579cc3a5cb2955161a8a322f0b
Cr-Commit-Position: refs/heads/master@{#292592}