Expose GLES2Interface to blink, and delete isContextLost() from WGC3D.

Expose GLES2Interface to blink, and delete isContextLost() from WGC3D.

This deletes the isContextLost() method from WebGraphicsContext3D, as
an example, and replaces calls to that in blink by called to
GetGraphicsResetStatusKHR() on the GLES2Interface directly.

R=esprehn@chromium.org, kbr@chromium.org, zmo@chromium.org
BUG=584497
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel

Committed: https://crrev.com/cdf8787552cc045c829fb7c6a43973d2452b8f4c
Cr-Commit-Position: refs/heads/master@{#381392}

[danakj, 2016-03-11 23:23:11]

Description was changed from

==========
Expose GLES2Interface to blink, and delete isContextLost() from WGC3D.

This deletes the isContextLost() method from WebGraphicsContext3D, as
an example, and replaces calls to that in blink by called to
GetGraphicsResetStatusKHR() on the GLES2Interface directly.

R=esprehn@chromium.org, kbr@chromium.org, zmo@chromium.org
BUG=584497
==========

to

==========
Expose GLES2Interface to blink, and delete isContextLost() from WGC3D.

This deletes the isContextLost() method from WebGraphicsContext3D, as
an example, and replaces calls to that in blink by called to
GetGraphicsResetStatusKHR() on the GLES2Interface directly.

R=esprehn@chromium.org, kbr@chromium.org, zmo@chromium.org
BUG=584497
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[Ken Russell (switch to Gerrit), 2016-03-14 20:17:42]

How will WebGraphicsContext3DInProcessCommandBufferImpl (the other primary
WebGraphicsContext3D subclass, after WebGraphicsContext3DCommandBufferImpl) be
handled after WebGraphicsContext3D is removed?

What about TestWebGraphicsContext3D, used by cc/? Is that type totally unrelated
to WebGraphicsContext3D?

Removing unnecessary abstraction layers is certainly a good direction and
WebGraphicsContext3D seems unnecessary at this point, but there may be some
dependencies that haven't been exposed yet.

[danakj, 2016-03-14 21:05:23]

On Mon, Mar 14, 2016 at 1:17 PM, <kbr@chromium.org> wrote:

> How will WebGraphicsContext3DInProcessCommandBufferImpl (the other primary
> WebGraphicsContext3D subclass, after
> WebGraphicsContext3DCommandBufferImpl) be
> handled after WebGraphicsContext3D is removed?
>

I didn't look at it in detail but my thought was that the code there either
needs to move up (into GLES2Impl or something), or down (into the callers
of it). Do you think it needs to be a (virtual?) intermediary as opposed to
a helper class of some sort? (I am not very familiar with the innards of
it.)


> What about TestWebGraphicsContext3D, used by cc/? Is that type totally
> unrelated
> to WebGraphicsContext3D?
>

They are unrelated. Just named alike at this point.


>
> Removing unnecessary abstraction layers is certainly a good direction and
> WebGraphicsContext3D seems unnecessary at this point, but there may be some
> dependencies that haven't been exposed yet.
>
>
> https://codereview.chromium.org/1790753002/
>

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[danakj, 2016-03-14 21:05:24]

On Mon, Mar 14, 2016 at 1:17 PM, <kbr@chromium.org> wrote:

> How will WebGraphicsContext3DInProcessCommandBufferImpl (the other primary
> WebGraphicsContext3D subclass, after
> WebGraphicsContext3DCommandBufferImpl) be
> handled after WebGraphicsContext3D is removed?
>

I didn't look at it in detail but my thought was that the code there either
needs to move up (into GLES2Impl or something), or down (into the callers
of it). Do you think it needs to be a (virtual?) intermediary as opposed to
a helper class of some sort? (I am not very familiar with the innards of
it.)


> What about TestWebGraphicsContext3D, used by cc/? Is that type totally
> unrelated
> to WebGraphicsContext3D?
>

They are unrelated. Just named alike at this point.


>
> Removing unnecessary abstraction layers is certainly a good direction and
> WebGraphicsContext3D seems unnecessary at this point, but there may be some
> dependencies that haven't been exposed yet.
>
>
> https://codereview.chromium.org/1790753002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Russell (switch to Gerrit), 2016-03-14 21:09:49]

On 2016/03/14 21:05:24, danakj wrote:
> On Mon, Mar 14, 2016 at 1:17 PM, <mailto:kbr@chromium.org> wrote:
> 
> > How will WebGraphicsContext3DInProcessCommandBufferImpl (the other primary
> > WebGraphicsContext3D subclass, after
> > WebGraphicsContext3DCommandBufferImpl) be
> > handled after WebGraphicsContext3D is removed?
> >
> 
> I didn't look at it in detail but my thought was that the code there either
> needs to move up (into GLES2Impl or something), or down (into the callers
> of it). Do you think it needs to be a (virtual?) intermediary as opposed to
> a helper class of some sort? (I am not very familiar with the innards of
> it.)

I took a look earlier and it looks like it instantiates a GLES2Interface in a
different way, so hopefully it could just be a helper class.

Removing this abstraction layer would be nice, but it's fairly large and needs
an owner to carry it through. I'm not sure Issue 584497 should block Issue
578344.

[danakj, 2016-03-14 21:12:28]

On Mon, Mar 14, 2016 at 2:09 PM, <kbr@chromium.org> wrote:

> On 2016/03/14 21:05:24, danakj wrote:
> > On Mon, Mar 14, 2016 at 1:17 PM, <mailto:kbr@chromium.org> wrote:
> >
> > > How will WebGraphicsContext3DInProcessCommandBufferImpl (the other
> primary
> > > WebGraphicsContext3D subclass, after
> > > WebGraphicsContext3DCommandBufferImpl) be
> > > handled after WebGraphicsContext3D is removed?
> > >
> >
> > I didn't look at it in detail but my thought was that the code there
> either
> > needs to move up (into GLES2Impl or something), or down (into the callers
> > of it). Do you think it needs to be a (virtual?) intermediary as opposed
> to
> > a helper class of some sort? (I am not very familiar with the innards of
> > it.)
>
> I took a look earlier and it looks like it instantiates a GLES2Interface
> in a
> different way, so hopefully it could just be a helper class.
>

Awesome thanks.


> Removing this abstraction layer would be nice, but it's fairly large and
> needs
> an owner to carry it through. I'm not sure Issue 584497 should block Issue
> 578344.
>

I was intending to do it all, yeah, but it's kinda being blocked by blink
folks atm. At which point I'm inclined to just capitalize functions and
move on. :/

If you can convince them I'm happy to poke away at this, I think it'd be
really nice.

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2016-03-14 21:17:51]

On Mon, Mar 14, 2016 at 2:09 PM, <kbr@chromium.org> wrote:

> On 2016/03/14 21:05:24, danakj wrote:
> > On Mon, Mar 14, 2016 at 1:17 PM, <mailto:kbr@chromium.org> wrote:
> >
> > > How will WebGraphicsContext3DInProcessCommandBufferImpl (the other
> primary
> > > WebGraphicsContext3D subclass, after
> > > WebGraphicsContext3DCommandBufferImpl) be
> > > handled after WebGraphicsContext3D is removed?
> > >
> >
> > I didn't look at it in detail but my thought was that the code there
> either
> > needs to move up (into GLES2Impl or something), or down (into the callers
> > of it). Do you think it needs to be a (virtual?) intermediary as opposed
> to
> > a helper class of some sort? (I am not very familiar with the innards of
> > it.)
>
> I took a look earlier and it looks like it instantiates a GLES2Interface
> in a
> different way, so hopefully it could just be a helper class.
>

Awesome thanks.


> Removing this abstraction layer would be nice, but it's fairly large and
> needs
> an owner to carry it through. I'm not sure Issue 584497 should block Issue
> 578344.
>

I was intending to do it all, yeah, but it's kinda being blocked by blink
folks atm. At which point I'm inclined to just capitalize functions and
move on. :/

If you can convince them I'm happy to poke away at this, I think it'd be
really nice.

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
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), 2016-03-14 23:02:45]

On 2016/03/14 21:17:51, danakj wrote:
> On Mon, Mar 14, 2016 at 2:09 PM, <mailto:kbr@chromium.org> wrote:
> 
> > On 2016/03/14 21:05:24, danakj wrote:
> > > On Mon, Mar 14, 2016 at 1:17 PM, <mailto:kbr@chromium.org> wrote:
> > >
> > > > How will WebGraphicsContext3DInProcessCommandBufferImpl (the other
> > primary
> > > > WebGraphicsContext3D subclass, after
> > > > WebGraphicsContext3DCommandBufferImpl) be
> > > > handled after WebGraphicsContext3D is removed?
> > > >
> > >
> > > I didn't look at it in detail but my thought was that the code there
> > either
> > > needs to move up (into GLES2Impl or something), or down (into the callers
> > > of it). Do you think it needs to be a (virtual?) intermediary as opposed
> > to
> > > a helper class of some sort? (I am not very familiar with the innards of
> > > it.)
> >
> > I took a look earlier and it looks like it instantiates a GLES2Interface
> > in a
> > different way, so hopefully it could just be a helper class.
> >
> 
> Awesome thanks.
> 
> 
> > Removing this abstraction layer would be nice, but it's fairly large and
> > needs
> > an owner to carry it through. I'm not sure Issue 584497 should block Issue
> > 578344.
> >
> 
> I was intending to do it all, yeah, but it's kinda being blocked by blink
> folks atm. At which point I'm inclined to just capitalize functions and
> move on. :/
> 
> If you can convince them I'm happy to poke away at this, I think it'd be
> really nice.

Replied to the email thread.

[Ken Russell (switch to Gerrit), 2016-03-15 00:53:10]

On 2016/03/14 23:02:45, Ken Russell wrote:
> On 2016/03/14 21:17:51, danakj wrote:
> > On Mon, Mar 14, 2016 at 2:09 PM, <mailto:kbr@chromium.org> wrote:
> > 
> > > On 2016/03/14 21:05:24, danakj wrote:
> > > > On Mon, Mar 14, 2016 at 1:17 PM, <mailto:kbr@chromium.org> wrote:
> > > >
> > > > > How will WebGraphicsContext3DInProcessCommandBufferImpl (the other
> > > primary
> > > > > WebGraphicsContext3D subclass, after
> > > > > WebGraphicsContext3DCommandBufferImpl) be
> > > > > handled after WebGraphicsContext3D is removed?
> > > > >
> > > >
> > > > I didn't look at it in detail but my thought was that the code there
> > > either
> > > > needs to move up (into GLES2Impl or something), or down (into the
callers
> > > > of it). Do you think it needs to be a (virtual?) intermediary as opposed
> > > to
> > > > a helper class of some sort? (I am not very familiar with the innards of
> > > > it.)
> > >
> > > I took a look earlier and it looks like it instantiates a GLES2Interface
> > > in a
> > > different way, so hopefully it could just be a helper class.
> > >
> > 
> > Awesome thanks.
> > 
> > 
> > > Removing this abstraction layer would be nice, but it's fairly large and
> > > needs
> > > an owner to carry it through. I'm not sure Issue 584497 should block Issue
> > > 578344.
> > >
> > 
> > I was intending to do it all, yeah, but it's kinda being blocked by blink
> > folks atm. At which point I'm inclined to just capitalize functions and
> > move on. :/
> > 
> > If you can convince them I'm happy to poke away at this, I think it'd be
> > really nice.
> 
> Replied to the email thread.

Per discussion on platform-architecture-dev@ it sounds like this refactoring is
unblocked, though in order to finish removing WebGraphicsContext3D, a few helper
functions will need to be added. How does that sound?

[piman, 2016-03-15 01:28:37]

piman@chromium.org changed reviewers:
+ piman@chromium.org

[piman, 2016-03-15 01:28:37]

LGTM for content/ and gpu/

[Ken Russell (switch to Gerrit), 2016-03-15 01:53:09]

Blink Source/modules/webgl/ and Source/platform/graphics/ LGTM, though junov
should probably sign off on Canvas2DLayerBridge.cpp.

https://codereview.chromium.org/1790753002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h (right):

https://codereview.chromium.org/1790753002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h:307:
gpu::gles2::GLES2Interface* m_gl; // Lifetime is tied to the m_context.
Thanks for this comment. :)

[Justin Novosad, 2016-03-15 15:35:49]

On 2016/03/15 01:53:09, Ken Russell wrote:
> Blink Source/modules/webgl/ and Source/platform/graphics/ LGTM, though junov
> should probably sign off on Canvas2DLayerBridge.cpp.
> 
>
https://codereview.chromium.org/1790753002/diff/1/third_party/WebKit/Source/p...
> File third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h (right):
> 
>
https://codereview.chromium.org/1790753002/diff/1/third_party/WebKit/Source/p...
> third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h:307:
> gpu::gles2::GLES2Interface* m_gl; // Lifetime is tied to the m_context.
> Thanks for this comment. :)

lgtm for Canvas2DLayerBridge

[danakj, 2016-03-15 19:42:49]

esprehn can you review public/ ?

[danakj, 2016-03-15 19:42:56]

The CQ bit was checked by danakj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-15 19:43:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1790753002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1790753002/1

[commit-bot: I haz the power, 2016-03-15 19:47:39]

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

[commit-bot: I haz the power, 2016-03-15 19:47:40]

Dry run: Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  linux_chromium_compile_dbg_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[chrishtr, 2016-03-15 20:41:04]

chrishtr@chromium.org changed reviewers:
+ chrishtr@chromium.org, junov@chromium.org

[chrishtr, 2016-03-15 20:41:04]

lgtm

[esprehn, 2016-03-15 20:45:18]

lgtm

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h (right):

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h:54: virtual
gpu::gles2::GLES2Interface* getGLInterface() = 0;
this could just be glInterface() ?

[danakj, 2016-03-15 20:47:12]

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h (right):

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h:54: virtual
gpu::gles2::GLES2Interface* getGLInterface() = 0;
On 2016/03/15 20:45:17, esprehn wrote:
> this could just be glInterface() ?

Ya I think it could.

[danakj, 2016-03-15 20:54:29]

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h (right):

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h:54: virtual
gpu::gles2::GLES2Interface* getGLInterface() = 0;
On 2016/03/15 20:45:17, esprehn wrote:
> this could just be glInterface() ?

I guess this is weird and I didn't do it originally cuz it's making weird
capitalization.

It should be gLInterface, which of course is all O_o. glInterface works I guess,
but is illegal too. Some code calls this ContextGL() in chromium, and
WebGC3DImpl had it called GetGLInterface().

[esprehn, 2016-03-15 21:00:17]

On 2016/03/15 at 20:54:29, danakj wrote:
>
https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
> File third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h
(right):
> 
>
https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
> third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h:54: virtual
gpu::gles2::GLES2Interface* getGLInterface() = 0;
> On 2016/03/15 20:45:17, esprehn wrote:
> > this could just be glInterface() ?
> 
> I guess this is weird and I didn't do it originally cuz it's making weird
capitalization.
> 
> It should be gLInterface, which of course is all O_o. glInterface works I
guess, but is illegal too. Some code calls this ContextGL() in chromium, and
WebGC3DImpl had it called GetGLInterface().

Chromium naming is google3 naming, you're supposed to treat these like words.
ex. ComputeHtml() not ComputeHTML(). We decided new code would use the Word
casing instead of the CAPS casing a while ago on chromium-dev.

[danakj, 2016-03-15 21:08:03]

On Tue, Mar 15, 2016 at 2:00 PM, <esprehn@chromium.org> wrote:

> On 2016/03/15 at 20:54:29, danakj wrote:
> >
>
>
https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
> > File third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h
> (right):
> >
> >
>
>
https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
> > third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h:54:
> virtual
> gpu::gles2::GLES2Interface* getGLInterface() = 0;
> > On 2016/03/15 20:45:17, esprehn wrote:
> > > this could just be glInterface() ?
> >
> > I guess this is weird and I didn't do it originally cuz it's making weird
> capitalization.
> >
> > It should be gLInterface, which of course is all O_o. glInterface works I
> guess, but is illegal too. Some code calls this ContextGL() in chromium,
> and
> WebGC3DImpl had it called GetGLInterface().
>
> Chromium naming is google3 naming, you're supposed to treat these like
> words.
> ex. ComputeHtml() not ComputeHTML(). We decided new code would use the Word
> casing instead of the CAPS casing a while ago on chromium-dev.
>

Yeh, but we also decided to be consistent with existing acronyms. I don't
think we'll ever write Gl for GL.. it'd be inconsistent with the GL headers
as well.


>
> https://codereview.chromium.org/1790753002/
>

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[danakj, 2016-03-15 21:09:06]

On Tue, Mar 15, 2016 at 2:00 PM, <esprehn@chromium.org> wrote:

> On 2016/03/15 at 20:54:29, danakj wrote:
> >
>
>
https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
> > File third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h
> (right):
> >
> >
>
>
https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
> > third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h:54:
> virtual
> gpu::gles2::GLES2Interface* getGLInterface() = 0;
> > On 2016/03/15 20:45:17, esprehn wrote:
> > > this could just be glInterface() ?
> >
> > I guess this is weird and I didn't do it originally cuz it's making weird
> capitalization.
> >
> > It should be gLInterface, which of course is all O_o. glInterface works I
> guess, but is illegal too. Some code calls this ContextGL() in chromium,
> and
> WebGC3DImpl had it called GetGLInterface().
>
> Chromium naming is google3 naming, you're supposed to treat these like
> words.
> ex. ComputeHtml() not ComputeHTML(). We decided new code would use the Word
> casing instead of the CAPS casing a while ago on chromium-dev.
>

Yeh, but we also decided to be consistent with existing acronyms. I don't
think we'll ever write Gl for GL.. it'd be inconsistent with the GL headers
as well.


>
> https://codereview.chromium.org/1790753002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2016-03-15 21:22:06]

I had to update the canvas tests and add a MockGLES2Interface. junov PTAL!

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h (right):

https://codereview.chromium.org/1790753002/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebGraphicsContext3DProvider.h:54: virtual
gpu::gles2::GLES2Interface* getGLInterface() = 0;
On 2016/03/15 20:54:29, danakj wrote:
> On 2016/03/15 20:45:17, esprehn wrote:
> > this could just be glInterface() ?
> 
> I guess this is weird and I didn't do it originally cuz it's making weird
> capitalization.
> 
> It should be gLInterface, which of course is all O_o. glInterface works I
guess,
> but is illegal too. Some code calls this ContextGL() in chromium, and
> WebGC3DImpl had it called GetGLInterface().

Renamed it to contextGL() to match the naming used elsewhere in chromium (other
than in the class we're going to delete).

[danakj, 2016-03-15 22:08:54]

kbr@ i also had to update the DrawingBuffer tests, PTAL

[Ken Russell (switch to Gerrit), 2016-03-15 22:09:40]

Thanks, still LGTM.

[danakj, 2016-03-15 22:48:54]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-03-15 22:48:55]

The patchset sent to the CQ was uploaded after l-g-t-m from junov@chromium.org,
piman@chromium.org, chrishtr@chromium.org, esprehn@chromium.org,
kbr@chromium.org
Link to the patchset: https://codereview.chromium.org/1790753002/#ps140001
(title: "wgc3d: deps-for-tests")

[commit-bot: I haz the power, 2016-03-15 22:49:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1790753002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1790753002/140001

[danakj, 2016-03-16 00:35:42]

Patchset #9 (id:160001) has been deleted

[danakj, 2016-03-16 00:35:55]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-03-16 00:35:55]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
chrishtr@chromium.org, esprehn@chromium.org, junov@chromium.org,
piman@chromium.org
Link to the patchset: https://codereview.chromium.org/1790753002/#ps140001
(title: "wgc3d: deps-for-tests")

[commit-bot: I haz the power, 2016-03-16 00:36:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1790753002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1790753002/140001

[commit-bot: I haz the power, 2016-03-16 05:22:49]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-03-16 05:25:00]

Description was changed from

==========
Expose GLES2Interface to blink, and delete isContextLost() from WGC3D.

This deletes the isContextLost() method from WebGraphicsContext3D, as
an example, and replaces calls to that in blink by called to
GetGraphicsResetStatusKHR() on the GLES2Interface directly.

R=esprehn@chromium.org, kbr@chromium.org, zmo@chromium.org
BUG=584497
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
Expose GLES2Interface to blink, and delete isContextLost() from WGC3D.

This deletes the isContextLost() method from WebGraphicsContext3D, as
an example, and replaces calls to that in blink by called to
GetGraphicsResetStatusKHR() on the GLES2Interface directly.

R=esprehn@chromium.org, kbr@chromium.org, zmo@chromium.org
BUG=584497
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel

Committed: https://crrev.com/cdf8787552cc045c829fb7c6a43973d2452b8f4c
Cr-Commit-Position: refs/heads/master@{#381392}
==========

[commit-bot: I haz the power, 2016-03-16 05:25:02]

Patchset 8 (id:??) landed as
https://crrev.com/cdf8787552cc045c829fb7c6a43973d2452b8f4c
Cr-Commit-Position: refs/heads/master@{#381392}