Use GrGLTextureInfo for Skia texture handles.

Use GrGLTextureInfo for Skia texture handles.

Currently Chromium's Skia build uses the old interface for moving textures in and out of Ganesh using a #define. This change updates callers to use the new type that communicates the texture target in addition to the ID. This is needed to support Chromium/skia interop for rectangle and external_oes textures.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/6b8d63efcd6214ebd5477b4bb5ad944a68f6de1c
Cr-Commit-Position: refs/heads/master@{#378136}

[bsalomon, 2015-12-07 21:28:42]

Description was changed from

==========
Use GrGLTextureInfo for Skia texture handles.
==========

to

==========
Use GrGLTextureInfo for Skia texture handles.
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[bsalomon, 2015-12-16 16:04:17]

Description was changed from

==========
Use GrGLTextureInfo for Skia texture handles.
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Use GrGLTextureInfo for Skia texture handles.

Currently Chromium's Skia build uses the old interface for moving textures in
and out of Ganesh using a #define. This change updates callers to use the new
type that communicates the texture target in addition to the ID. This is needed
to support Chromium/skia interop for rectangle and external_oes textures.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[bsalomon, 2015-12-16 16:04:17]

bsalomon@google.com changed reviewers:
+ dalecurtis@chromium.org, dcastagna@chromium.org, enne@chromium.org,
senorblanco@chromium.org

[bsalomon, 2015-12-16 16:47:47]

The CQ bit was checked by bsalomon@google.com to run a CQ dry run

[commit-bot: I haz the power, 2015-12-16 16:48:11]

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

[commit-bot: I haz the power, 2015-12-16 16:48:12]

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

[commit-bot: I haz the power, 2015-12-16 16:48:12]

Dry run: No L-G-T-M from a valid reviewer yet. Only full committers are
accepted.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Daniele Castagna, 2015-12-16 17:25:51]

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
File media/renderers/skcanvas_video_renderer.cc (right):

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:127:
DCHECK_LE(source_textures[0].fID,
We can get rid of these DCHECKs since fID is unsigned.

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:151: color_space, handles, yuvSizes,
Can't we just have NewFromYUVTexturesCopy take a GrGLTextureInfo[] instead of
GrBackendObject[]?

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:201: desc.fTextureHandle =
static_cast<int>(source_texture);
Should we change this one too?

[bsalomon, 2015-12-16 18:09:02]

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
File media/renderers/skcanvas_video_renderer.cc (right):

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:127:
DCHECK_LE(source_textures[0].fID,
On 2015/12/16 17:25:51, Daniele Castagna wrote:
> We can get rid of these DCHECKs since fID is unsigned.

Done.

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:151: color_space, handles, yuvSizes,
On 2015/12/16 17:25:51, Daniele Castagna wrote:
> Can't we just have NewFromYUVTexturesCopy take a GrGLTextureInfo[] instead of
> GrBackendObject[]?

We could do that (and similar for all other uses of GrBackendObject) but I'd
prefer not to have duplicate entries for GL, Vulkan, ...

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:201: desc.fTextureHandle =
static_cast<int>(source_texture);
On 2015/12/16 17:25:51, Daniele Castagna wrote:
> Should we change this one too?

Yep, done.

[Daniele Castagna, 2015-12-16 19:30:18]

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
File media/renderers/skcanvas_video_renderer.cc (right):

https://codereview.chromium.org/1508903002/diff/40001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:151: color_space, handles, yuvSizes,
On 2015/12/16 at 18:09:02, bsalomon wrote:
> On 2015/12/16 17:25:51, Daniele Castagna wrote:
> > Can't we just have NewFromYUVTexturesCopy take a GrGLTextureInfo[] instead
of
> > GrBackendObject[]?
> 
> We could do that (and similar for all other uses of GrBackendObject) but I'd
prefer not to have duplicate entries for GL, Vulkan, ...

Acknowledged.

https://codereview.chromium.org/1508903002/diff/60001/media/renderers/skcanva...
File media/renderers/skcanvas_video_renderer.cc (right):

https://codereview.chromium.org/1508903002/diff/60001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:193: GrGLTextureInfo
sourceTextureInfo;
nit: the name should be all lower case, with underscores between words.

https://codereview.chromium.org/1508903002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
(right):

https://codereview.chromium.org/1508903002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp:606: GLuint
textureID = reinterpret_cast<const
GrGLTextureInfo*>(mailboxInfo.m_image->getTexture()->getTextureHandle())->fID;
nit: this line seems to long.

https://codereview.chromium.org/1508903002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp
(right):

https://codereview.chromium.org/1508903002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp:161:
unsigned textureId = reinterpret_cast<const
GrGLTextureInfo*>(bridge->newImageSnapshot(PreferAcceleration)->getTextureHandle(true))->fID;
nit: line too long? Did you run "git cl format"?

[bsalomon, 2015-12-16 20:06:36]

https://codereview.chromium.org/1508903002/diff/60001/media/renderers/skcanva...
File media/renderers/skcanvas_video_renderer.cc (right):

https://codereview.chromium.org/1508903002/diff/60001/media/renderers/skcanva...
media/renderers/skcanvas_video_renderer.cc:193: GrGLTextureInfo
sourceTextureInfo;
On 2015/12/16 19:30:18, Daniele Castagna wrote:
> nit: the name should be all lower case, with underscores between words.

Done.

https://codereview.chromium.org/1508903002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp
(right):

https://codereview.chromium.org/1508903002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp:161:
unsigned textureId = reinterpret_cast<const
GrGLTextureInfo*>(bridge->newImageSnapshot(PreferAcceleration)->getTextureHandle(true))->fID;
On 2015/12/16 19:30:18, Daniele Castagna wrote:
> nit: line too long? Did you run "git cl format"?

I did and it didn't produce a diff. Am I wrong that third_party/WebKit code does
not wrap lines?

[Stephen White, 2015-12-16 22:13:31]

All of those reinterpret_casts seem really unfortunate. Especially the one that
takes a pointer to a stack-allocated object and puts it in a texture desc (see
below). If that desc were copied by the callee, it would be pointing at garbage
after the function returns.

Could we change Skia to have some kind of texture info class that contains
"texture handle" and "texture target", and make *those* anonymous (e.g.,
GrTextureHandle and GrTextureTarget that are both intptr_t or something). Then
you could put one of those by value in the GrTextureDesc, and there'd be no
memory danger, at least.

https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
File cc/resources/resource_provider.cc (right):

https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
cc/resources/resource_provider.cc:972: desc.fTextureHandle =
reinterpret_cast<GrBackendObject>(&texture_info);
This seems fragile. If he callee copied this desc before texture_info goes out
of scope, it'd be pointing at garbage.

[bsalomon, 2015-12-17 16:52:03]

On 2015/12/16 22:13:31, Stephen White wrote:
> All of those reinterpret_casts seem really unfortunate. Especially the one
that
> takes a pointer to a stack-allocated object and puts it in a texture desc (see
> below). If that desc were copied by the callee, it would be pointing at
garbage
> after the function returns.
> 
> Could we change Skia to have some kind of texture info class that contains
> "texture handle" and "texture target", and make *those* anonymous (e.g.,
> GrTextureHandle and GrTextureTarget that are both intptr_t or something). Then
> you could put one of those by value in the GrTextureDesc, and there'd be no
> memory danger, at least.
> 
>
https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
> File cc/resources/resource_provider.cc (right):
> 
>
https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
> cc/resources/resource_provider.cc:972: desc.fTextureHandle =
> reinterpret_cast<GrBackendObject>(&texture_info);
> This seems fragile. If he callee copied this desc before texture_info goes out
> of scope, it'd be pointing at garbage.

dcastagna@ raised similar concerns offline. There is a wrinkle that there exists
another interpretation of GrBackendObject for another backend that is not yet in
the public Skia repo and is not an id/target pair.

[ericrk, 2016-02-19 21:28:36]

On 2015/12/17 16:52:03, bsalomon wrote:
> On 2015/12/16 22:13:31, Stephen White wrote:
> > All of those reinterpret_casts seem really unfortunate. Especially the one
> that
> > takes a pointer to a stack-allocated object and puts it in a texture desc
(see
> > below). If that desc were copied by the callee, it would be pointing at
> garbage
> > after the function returns.
> > 
> > Could we change Skia to have some kind of texture info class that contains
> > "texture handle" and "texture target", and make *those* anonymous (e.g.,
> > GrTextureHandle and GrTextureTarget that are both intptr_t or something).
Then
> > you could put one of those by value in the GrTextureDesc, and there'd be no
> > memory danger, at least.
> > 
> >
>
https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
> > File cc/resources/resource_provider.cc (right):
> > 
> >
>
https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
> > cc/resources/resource_provider.cc:972: desc.fTextureHandle =
> > reinterpret_cast<GrBackendObject>(&texture_info);
> > This seems fragile. If he callee copied this desc before texture_info goes
out
> > of scope, it'd be pointing at garbage.
> 
> dcastagna@ raised similar concerns offline. There is a wrinkle that there
exists
> another interpretation of GrBackendObject for another backend that is not yet
in
> the public Skia repo and is not an id/target pair.

I understand the hesitation here, but would like to progress on this as I have a
dependency on the new texture specification
for some of the GPU raster work I'm doing. It seems like we can either land this
as-is, land this with TODOs and a tracking
bug to improve the interface in the future, or re-work the interface now.

From the concerns Brian raised, I'm not sure whether re-working the interface is
trivial with the multiple implementations
of GrBackendObject in play. It sounds like the data that would need to go in the
texture info class might need to be
different depending on the backend. Not sure that there's a nice way to
accomplish this, unless perhaps we make all these
structs into more full fledged interfaces that Skia creates - not sure if this
is worth the overhead?

WDYT?

[Daniele Castagna, 2016-02-19 21:44:05]

On 2016/02/19 at 21:28:36, ericrk wrote:
> On 2015/12/17 16:52:03, bsalomon wrote:
> > On 2015/12/16 22:13:31, Stephen White wrote:
> > > All of those reinterpret_casts seem really unfortunate. Especially the one
> > that
> > > takes a pointer to a stack-allocated object and puts it in a texture desc
(see
> > > below). If that desc were copied by the callee, it would be pointing at
> > garbage
> > > after the function returns.
> > > 
> > > Could we change Skia to have some kind of texture info class that contains
> > > "texture handle" and "texture target", and make *those* anonymous (e.g.,
> > > GrTextureHandle and GrTextureTarget that are both intptr_t or something).
Then
> > > you could put one of those by value in the GrTextureDesc, and there'd be
no
> > > memory danger, at least.
> > > 
> > >
> >
https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
> > > File cc/resources/resource_provider.cc (right):
> > > 
> > >
> >
https://codereview.chromium.org/1508903002/diff/100001/cc/resources/resource_...
> > > cc/resources/resource_provider.cc:972: desc.fTextureHandle =
> > > reinterpret_cast<GrBackendObject>(&texture_info);
> > > This seems fragile. If he callee copied this desc before texture_info goes
out
> > > of scope, it'd be pointing at garbage.
> > 
> > dcastagna@ raised similar concerns offline. There is a wrinkle that there
exists
> > another interpretation of GrBackendObject for another backend that is not
yet in
> > the public Skia repo and is not an id/target pair.
> 
> I understand the hesitation here, but would like to progress on this [...]

+1
Being able to specify the imported texture target would be beneficial for video
to canvas as well (used by Youtube 360 and facebook 360 video).

[bsalomon, 2016-02-22 16:37:38]

Personally I think the risk here is pretty low. Skia doesn't retain the
GrGLTextureInfo pointer. Skia's API takes un-retainable pointers in many its
APIs. The only difference I see here is that the type is opaque. The other API
backends (Vulkan, and presumably future additions like Metal or D3D) would not
be a target and id combo.

[Stephen White, 2016-02-22 16:41:10]

On 2016/02/22 16:37:38, bsalomon wrote:
> Personally I think the risk here is pretty low. Skia doesn't retain the
> GrGLTextureInfo pointer. Skia's API takes un-retainable pointers in many its
> APIs. The only difference I see here is that the type is opaque. The other API
> backends (Vulkan, and presumably future additions like Metal or D3D) would not
> be a target and id combo.

Aside from the safety issue, are there plans for a better API? It seems strange 
that we need reinterpret_cast<> in a public API to Skia.

Could we at least hide the ugly inside Skia? Maybe some kind of GL-specific
helper 
function that builds the appropriate GrBackendObject?

[ericrk, 2016-02-22 21:09:57]

On 2016/02/22 16:41:10, Stephen White wrote:
> On 2016/02/22 16:37:38, bsalomon wrote:
> > Personally I think the risk here is pretty low. Skia doesn't retain the
> > GrGLTextureInfo pointer. Skia's API takes un-retainable pointers in many its
> > APIs. The only difference I see here is that the type is opaque. The other
API
> > backends (Vulkan, and presumably future additions like Metal or D3D) would
not
> > be a target and id combo.
> 
> Aside from the safety issue, are there plans for a better API? It seems
strange 
> that we need reinterpret_cast<> in a public API to Skia.
> 
> Could we at least hide the ugly inside Skia? Maybe some kind of GL-specific
> helper 
> function that builds the appropriate GrBackendObject?

What about something as simple as:
const GrBackendObject GrGLTextureInfo::asBackendObject() const;
static const GrGLTextureInfo* GrGLTextureInfo::fromBackendObject(const
GrBackendObject object);

This leaves us open to later augmenting the various backend object structs with
some sort of "class ID" value that could be checked in "fromBackendOBject". We
could design this so that "fromBackendObject" could fail (although in the
current world with 1 type, it would never happen). This would let us improve
things when we add a second type without changing client code?

[bsalomon, 2016-02-23 02:29:39]

On 2016/02/22 21:09:57, ericrk wrote:
> On 2016/02/22 16:41:10, Stephen White wrote:
> > On 2016/02/22 16:37:38, bsalomon wrote:
> > > Personally I think the risk here is pretty low. Skia doesn't retain the
> > > GrGLTextureInfo pointer. Skia's API takes un-retainable pointers in many
its
> > > APIs. The only difference I see here is that the type is opaque. The other
> API
> > > backends (Vulkan, and presumably future additions like Metal or D3D) would
> not
> > > be a target and id combo.
> > 
> > Aside from the safety issue, are there plans for a better API? It seems
> strange 
> > that we need reinterpret_cast<> in a public API to Skia.
> > 
> > Could we at least hide the ugly inside Skia? Maybe some kind of GL-specific
> > helper 
> > function that builds the appropriate GrBackendObject?
> 
> What about something as simple as:
> const GrBackendObject GrGLTextureInfo::asBackendObject() const;
> static const GrGLTextureInfo* GrGLTextureInfo::fromBackendObject(const
> GrBackendObject object);
> 
> This leaves us open to later augmenting the various backend object structs
with
> some sort of "class ID" value that could be checked in "fromBackendOBject". We
> could design this so that "fromBackendObject" could fail (although in the
> current world with 1 type, it would never happen). This would let us improve
> things when we add a second type without changing client code?

That seems reasonable to me. We could also make a GrBackendTextureInfo class
that is opaque externally but can be constructed from a GrGLTextureInfo or a
Vulkan equivalent. It'd be more involved than your suggestion in terms since we
use GrGLTextureInfo*/GrBackendObject aliasing internally in our tests, but not a
huge change.

[bsalomon, 2016-02-25 13:26:56]

Would it be OK to land this with a TODO to change the Skia API to make this more
typesafe? I'll file a bug for this, but should I also place a TODO in a comment
somewhere?

[Stephen White, 2016-02-25 17:53:52]

On 2016/02/25 13:26:56, bsalomon wrote:
> Would it be OK to land this with a TODO to change the Skia API to make this
more
> typesafe? I'll file a bug for this, but should I also place a TODO in a
comment
> somewhere?

That sounds ok. Please mark the bug for a particular milestone, so it doesn't
get lost.

As an interim measure, would it be possible to centralize the
reinterpret_cast<>s into 
some macros on the Chrome side? You could put them in SkUserConfig.h for now. 
Would that work?

[bsalomon, 2016-02-26 16:31:27]

Instead of adding conversion functions to SkUserConfig.h I added
skia/ext/texture_handle.h so that I could get the type definitions by including
GrGLTypes.h

[Stephen White, 2016-02-26 16:39:21]

Thanks! Much cleaner.

https://codereview.chromium.org/1508903002/diff/160001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/1508903002/diff/160001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:964: background_image_id = reinterpret_cast<const
GrGLTextureInfo*>(
Could you use GrBackendObjectToGrGLTextureInfo() here too?

https://codereview.chromium.org/1508903002/diff/160001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:1045: filter_image_id = reinterpret_cast<const
GrGLTextureInfo*>(
Could you use GrBackendObjectToGrGLTextureInfo() here too?

[bsalomon, 2016-02-26 16:51:45]

https://codereview.chromium.org/1508903002/diff/160001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/1508903002/diff/160001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:964: background_image_id = reinterpret_cast<const
GrGLTextureInfo*>(
On 2016/02/26 16:39:21, Stephen White wrote:
> Could you use GrBackendObjectToGrGLTextureInfo() here too?

Oops, done...

https://codereview.chromium.org/1508903002/diff/160001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:1045: filter_image_id = reinterpret_cast<const
GrGLTextureInfo*>(
On 2016/02/26 16:39:21, Stephen White wrote:
> Could you use GrBackendObjectToGrGLTextureInfo() here too?

...and done.

[Stephen White, 2016-02-26 18:34:07]

LGTM

[ericrk, 2016-02-26 19:34:58]

cc LGTM

[bsalomon, 2016-02-26 19:41:08]

On 2016/02/26 19:34:58, ericrk wrote:
> cc LGTM

I think that just leaves media. Dale?

[DaleCurtis, 2016-02-26 20:43:16]

media/ lgtm

https://codereview.chromium.org/1508903002/diff/180001/skia/ext/texture_handle.h
File skia/ext/texture_handle.h (right):

https://codereview.chromium.org/1508903002/diff/180001/skia/ext/texture_handl...
skia/ext/texture_handle.h:13: static inline GrBackendObject
GrGLTextureInfoToGrBackendObject(
static inline in a header file seems unusual.

[bsalomon, 2016-02-26 21:06:24]

On 2016/02/26 20:43:16, DaleCurtis wrote:
> media/ lgtm
> 
>
https://codereview.chromium.org/1508903002/diff/180001/skia/ext/texture_handle.h
> File skia/ext/texture_handle.h (right):
> 
>
https://codereview.chromium.org/1508903002/diff/180001/skia/ext/texture_handl...
> skia/ext/texture_handle.h:13: static inline GrBackendObject
> GrGLTextureInfoToGrBackendObject(
> static inline in a header file seems unusual.

Agreed, that static isn't necessary. I was just parroting the style used in
another header in this dir, though I now see others just use inline. I'll remove
the statics.

[bsalomon, 2016-02-26 21:08:30]

The CQ bit was checked by bsalomon@google.com

[bsalomon, 2016-02-26 21:08:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
senorblanco@chromium.org, dalecurtis@chromium.org, ericrk@chromium.org
Link to the patchset: https://codereview.chromium.org/1508903002/#ps200001
(title: "remove 'static' from 'static inline'")

[commit-bot: I haz the power, 2016-02-26 21:12:54]

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

[commit-bot: I haz the power, 2016-02-26 21:44:20]

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

[commit-bot: I haz the power, 2016-02-26 21:44:22]

Exceeded global retry quota

[bsalomon, 2016-02-27 14:46:55]

The CQ bit was checked by bsalomon@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-27 14:47:06]

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

[commit-bot: I haz the power, 2016-02-27 15:28:35]

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

[commit-bot: I haz the power, 2016-02-27 15:28:37]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[bsalomon, 2016-02-27 18:51:50]

The CQ bit was checked by bsalomon@google.com

[bsalomon, 2016-02-27 18:51:51]

The patchset sent to the CQ was uploaded after l-g-t-m from
senorblanco@chromium.org, dalecurtis@chromium.org, ericrk@chromium.org
Link to the patchset: https://codereview.chromium.org/1508903002/#ps240001
(title: "One more getTextureHandle in webmediaplayer_android")

[commit-bot: I haz the power, 2016-02-27 18:52:35]

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

[bsalomon, 2016-02-27 19:48:19]

The CQ bit was checked by bsalomon@google.com

[bsalomon, 2016-02-27 19:48:19]

The patchset sent to the CQ was uploaded after l-g-t-m from
senorblanco@chromium.org, dalecurtis@chromium.org, ericrk@chromium.org
Link to the patchset: https://codereview.chromium.org/1508903002/#ps260001
(title: "Set target type in from mailbox in skcanvas_video_renderer")

[commit-bot: I haz the power, 2016-02-27 19:48:34]

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

[commit-bot: I haz the power, 2016-02-27 23:28:35]

Description was changed from

==========
Use GrGLTextureInfo for Skia texture handles.

Currently Chromium's Skia build uses the old interface for moving textures in
and out of Ganesh using a #define. This change updates callers to use the new
type that communicates the texture target in addition to the ID. This is needed
to support Chromium/skia interop for rectangle and external_oes textures.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Use GrGLTextureInfo for Skia texture handles.

Currently Chromium's Skia build uses the old interface for moving textures in
and out of Ganesh using a #define. This change updates callers to use the new
type that communicates the texture target in addition to the ID. This is needed
to support Chromium/skia interop for rectangle and external_oes textures.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2016-02-27 23:28:37]

Committed patchset #14 (id:260001)

[commit-bot: I haz the power, 2016-02-27 23:29:53]

Description was changed from

==========
Use GrGLTextureInfo for Skia texture handles.

Currently Chromium's Skia build uses the old interface for moving textures in
and out of Ganesh using a #define. This change updates callers to use the new
type that communicates the texture target in addition to the ID. This is needed
to support Chromium/skia interop for rectangle and external_oes textures.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Use GrGLTextureInfo for Skia texture handles.

Currently Chromium's Skia build uses the old interface for moving textures in
and out of Ganesh using a #define. This change updates callers to use the new
type that communicates the texture target in addition to the ID. This is needed
to support Chromium/skia interop for rectangle and external_oes textures.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/6b8d63efcd6214ebd5477b4bb5ad944a68f6de1c
Cr-Commit-Position: refs/heads/master@{#378136}
==========

[commit-bot: I haz the power, 2016-02-27 23:29:56]

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