WebGraphicsContext3D

[Dana Jansens]

Hi,

I propose that we gut WebGraphicsContext3D and have blink use the gpu::gles2::GLES2Interface* directly. Is this okay with you? It means adding some gpu/ stuff to DEPS files for various parts of blink. This will let us kill a virtual for every webgl call, not bad right?

(Some minimal context https://bugs.chromium.org/p/chromium/issues/detail?id=584497)

- Dana

[Antoine Labour]

For extra background, GLES2Interface is in gpu/ not content/, and is fairly stable (1:1 with the OpenGL ES 2/3 API). WebGraphicsContext3D is essentially just a wrapper around GLES2Interface, with a bit of impedance matching.

Antoine

- Dana

[Zhenyao Mo]

+1

[Elliott Sprehn]

That's in platform/ right? Go for it.

[Dana Jansens]

On Fri, Mar 11, 2016 at 2:33 PM, Elliott Sprehn <esp...@chromium.org> wrote:

That's in platform/ right? Go for it.

Example places that will include gpu/:

third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp

third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp

third_party/WebKit/Source/platform/graphics/gpu/Extensions3DUtil.cpp

third_party/WebKit/Source/platform/graphics/gpu/SharedContextRateLimiter.cpp

So, ya, platform/ and modules/ it looks like (at least for the first function I'm trying).

[Elliott Sprehn]

I don't think we want modules/ including gpu, those interfaces are also using std::string. We should instead move webgraphicscontext3d_command_buffer_impl.cc and friends into blink platform probably to remove the indirections.

[Dana Jansens]

On Fri, Mar 11, 2016 at 2:38 PM, Elliott Sprehn <esp...@chromium.org> wrote:

I don't think we want modules/ including gpu, those interfaces are also using std::string. We should instead move webgraphicscontext3d_command_buffer_impl.cc and friends into blink platform probably to remove the indirections.

That went a bit over my head. How does moving WebGraphicsContext3dCommandBufferImpl help here?

I think to avoid modules/ using gpu/ you have to make some other interface in platform/ for it to use, and it calls to gpu/ things? (Do we really want to write yet another WebGraphicsContext3D to help us remove WebGraphicsContext3D?)

[Elliott Sprehn]

webgraphicscontext3d_command_buffer_impl.cc is the implementation of the virtual base classes you're talking about. Those indirections should be in blink platform. I don't think we should be pulling gpu/ stuff into modules. We can certainly move code from modules down into platform though if that's better.

[Dana Jansens]

On Fri, Mar 11, 2016 at 2:45 PM, Elliott Sprehn <esp...@chromium.org> wrote:

webgraphicscontext3d_command_buffer_impl.cc is the implementation of the virtual base classes you're talking about. Those indirections should be in blink platform. I don't think we should be pulling gpu/ stuff into modules. We can certainly move code from modules down into platform though if that's better.

I think WebGraphicsContext3DCommandBufferImpl should be deleted at some point, or maybe I'm misunderstanding. Blink can use GLES2Interface, so there's no need for any "WebGraphicsContext3D" anything at all, which wraps GLES2Interface with a Web api. Is this wrong?

[Dana Jansens]

On Fri, Mar 11, 2016 at 2:49 PM, Dana Jansens <dan...@google.com> wrote:

On Fri, Mar 11, 2016 at 2:45 PM, Elliott Sprehn <esp...@chromium.org> wrote:

webgraphicscontext3d_command_buffer_impl.cc is the implementation of the virtual base classes you're talking about. Those indirections should be in blink platform. I don't think we should be pulling gpu/ stuff into modules. We can certainly move code from modules down into platform though if that's better.

I think WebGraphicsContext3DCommandBufferImpl should be deleted at some point, or maybe I'm misunderstanding. Blink can use GLES2Interface, so there's no need for any "WebGraphicsContext3D" anything at all, which wraps GLES2Interface with a Web api. Is this wrong?

Actually, GLES2Interface does not use std::string AFAICT.

https://code.google.com/p/chromium/codesearch#chromium/src/gpu/command_buffer/client/gles2_interface.h&q=gles2interface&sq=package:chromium&type=cs

https://code.google.com/p/chromium/codesearch#chromium/src/gpu/command_buffer/client/gles2_interface_autogen.h&q=gpu/command_buffer/client/gles2_interface_autogen.h&sq=package:chromium&type=cs

It's an actual GL API, which does not use those.

[Elliott Sprehn]

I see that now, that seems more reason this should have a platform wrapper. Look at the incantations in:

https://code.google.com/p/chromium/codesearch#chromium/src/gpu/blink/webgraphicscontext3d_impl.cc&sq=package:chromium&l=516

I don't think we want that spread all over blink for any consumer of the low level API. Just like we don't use pthread APIs directly and use base thread stuff.

That's the whole purpose of platform/ it should make these low level APIs friendly.

[Dana Jansens]

On Fri, Mar 11, 2016 at 2:59 PM, Elliott Sprehn <esp...@chromium.org> wrote:

I see that now, that seems more reason this should have a platform wrapper. Look at the incantations in:

https://code.google.com/p/chromium/codesearch#chromium/src/gpu/blink/webgraphicscontext3d_impl.cc&sq=package:chromium&l=516

I don't think we want that spread all over blink for any consumer of the low level API. Just like we don't use pthread APIs directly and use base thread stuff.

Well, hm. Here's some of the things that the modules/webgl code is using from the GL context:

bindAttribLocation

attachShader

activeTexture

bindBuffer

bindRenderbuffer

bindTexture

blendColor

blendEquation

blendEquationSeparate

blendFunc

blendFuncSeparate

bufferData

checkFramebufferStatus

clear

clearColor

clearDepth

clearStencil

colorMask

compileShader

compressedTexImage2D

compressedTexSubImage2D

copyTexImage2D

copyTexSubImage2D

cullFace

depthMask

depthRange

detachShader

disable

disableVertexAttribArray

drawArrays

drawElements

drawArraysInstancedANGLE

enable

enableVertexAttribArray

flush

framebufferRenderbuffer

frontFace

generateMipmap

getActiveAttrib

getActiveUniform

getAttribLocation

getBufferParameteriv

getError

getFramebufferAttachmentParameteriv

getString

getProgramiv

getProgramInfoLog

getRenderbufferParameteriv

getShaderiv

getShaderInfoLog

getShaderPrecisionFormat

getTexParameteriv

getUniformLocation

getUniformfv

...

I stopped halfway thru the file.

I'm not sure what high level API you're expecting to provide here, GL already is a well known API that this code speaks. :/ And designing a higher level graphics API seems kinda out of scope here and not something I believe a good use of time here.

I just want to delete some virtuals and macros that call thru to other virtuals.

That's the whole purpose of platform/ it should make these low level APIs friendly.

I'd say that's a good argument why we should not add something to platform in this case. The API is well defined and stable and already exists in gpu::gles2.

We can add to platform the call-through macro-type things I'm trying to delete (maybe with one less virtual keyword along the way), at which point it's probably not worth doing anything right now until we sort out how to let modules/ use GLES2Interface, or move code out of modules/ entirely which is pretty far out of my understanding.

kbr? zmo? Thoughts?

[Elliott Sprehn]

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

[Dana Jansens]

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

Which 10-line incantations are you referring to? Well, here's an example CL: https://codereview.chromium.org/1790753002 so we can talk more concretely.

The CL changes mean that blink calls GLES2Interface::Foo() instead of WebGraphicsContext3D::foo() basically, and it gets the pointer from a sibling/replacement method (or off the WGC3D if it has to for now).

[Elliott Sprehn]

I linked to one, see for example the code in WebGraphicsContext3DImpl::getShaderInfoLog that converts to WebString.

[Antoine Labour]

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

What's this "all over blink" you're talking about? 

The only caller of WGC3D in modules is the WebGL context hookup. All it does is translating WebGL to GL, which is essentially the same thing. I'm not sure what extra "wrapper" you would want in the middle. WebGLRenderingContextBase *is* that wrapper.

Antoine

[Elliott Sprehn]

On Fri, Mar 11, 2016 at 3:31 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

What's this "all over blink" you're talking about? 

The only caller of WGC3D in modules is the WebGL context hookup. All it does is translating WebGL to GL, which is essentially the same thing. I'm not sure what extra "wrapper" you would want in the middle. WebGLRenderingContextBase *is* that wrapper.

No it's not, it's the idl mapped API surface speced for JS. That thing is not the same as the low level interface in blink that talks to gl with, for example WebGraphicsContext3D is used in the <video> element, Canvas2DLayerBridge, ImageBuffer, DrawingBuffer, etc.

If you want that to be the thing, then move it into platform. If you want to talk to the low level gl system, move it into platform. modules/ and core/ are not that thing.

- E

[Antoine Labour]

On Fri, Mar 11, 2016 at 3:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:31 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

What's this "all over blink" you're talking about? 

The only caller of WGC3D in modules is the WebGL context hookup. All it does is translating WebGL to GL, which is essentially the same thing. I'm not sure what extra "wrapper" you would want in the middle. WebGLRenderingContextBase *is* that wrapper.

No it's not, it's the idl mapped API surface speced for JS.

WebGL and GL are the same API. They're just as high or low level. I don't understand this discussion - it makes absolutely no sense to me.

Antoine

[Antoine Labour]

On Fri, Mar 11, 2016 at 3:43 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:31 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

What's this "all over blink" you're talking about? 

The only caller of WGC3D in modules is the WebGL context hookup. All it does is translating WebGL to GL, which is essentially the same thing. I'm not sure what extra "wrapper" you would want in the middle. WebGLRenderingContextBase *is* that wrapper.

No it's not, it's the idl mapped API surface speced for JS.

WebGL and GL are the same API. They're just as high or low level. I don't understand this discussion - it makes absolutely no sense to me.

As a base of comparison, WebGL is to GL just as 2D canvas is to Skia. 2D canvas->Skia is done in Source/modules/canvas2d/. If it works for Skia, why is it not acceptable for GL?

Antoine

[Elliott Sprehn]

On Fri, Mar 11, 2016 at 3:48 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:43 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:31 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

What's this "all over blink" you're talking about? 

The only caller of WGC3D in modules is the WebGL context hookup. All it does is translating WebGL to GL, which is essentially the same thing. I'm not sure what extra "wrapper" you would want in the middle. WebGLRenderingContextBase *is* that wrapper.

No it's not, it's the idl mapped API surface speced for JS.

WebGL and GL are the same API. They're just as high or low level. I don't understand this discussion - it makes absolutely no sense to me.

As a base of comparison, WebGL is to GL just as 2D canvas is to Skia. 2D canvas->Skia is done in Source/modules/canvas2d/. If it works for Skia, why is it not acceptable for GL?

What do you mean, CanvasRenderingContext2D uses abstractions like platform/graphics/Path.h. :)

Anyway I'm happy to talk this out over VC if you want to schedule a meeting. The parts of the system that have access to the DOM, ScriptValue, and all that stuff, are at a different abstraction layer.

- E 

[Zhenyao Mo]

On Fri, Mar 11, 2016 at 3:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:31 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

What's this "all over blink" you're talking about? 

The only caller of WGC3D in modules is the WebGL context hookup. All it does is translating WebGL to GL, which is essentially the same thing. I'm not sure what extra "wrapper" you would want in the middle. WebGLRenderingContextBase *is* that wrapper.

No it's not, it's the idl mapped API surface speced for JS. That thing is not the same as the low level interface in blink that talks to gl with, for example WebGraphicsContext3D is used in the <video> element, Canvas2DLayerBridge, ImageBuffer, DrawingBuffer, etc.

All clients of WebGraphicsContext3D are WebGL directly or indirectly. If you look at video, canvas, ImageBuffer, etc, their use of WebGraphcisContext3D is to feed data to WebGL textures. I've been wanting to move these functions into WebGLRenderingContext (haven't studied feasibility though).  DrawingBuffer is just for WebGL and nothing else is using it. That can be moved to modules/webgl/.

What I meant to say is, it's not all over blink. It's just WebGL.

[Antoine Labour]

On Fri, Mar 11, 2016 at 3:54 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:48 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:43 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:31 PM, Antoine Labour <pi...@chromium.org> wrote:

On Fri, Mar 11, 2016 at 3:20 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Doing those 10 line incantations to talk to GLES2Interface all over blink is not worth removing this stuff. I don't think the code rename being slightly harder is motivation either.

What's this "all over blink" you're talking about? 

The only caller of WGC3D in modules is the WebGL context hookup. All it does is translating WebGL to GL, which is essentially the same thing. I'm not sure what extra "wrapper" you would want in the middle. WebGLRenderingContextBase *is* that wrapper.

No it's not, it's the idl mapped API surface speced for JS.

WebGL and GL are the same API. They're just as high or low level. I don't understand this discussion - it makes absolutely no sense to me.

As a base of comparison, WebGL is to GL just as 2D canvas is to Skia. 2D canvas->Skia is done in Source/modules/canvas2d/. If it works for Skia, why is it not acceptable for GL?

What do you mean, CanvasRenderingContext2D uses abstractions like platform/graphics/Path.h. :)

BaseRenderingContext2D does the conversion of drawing commands to SkCanvas. That's in modules/.

GL (GLES2Interface) is the exact equivalent to SkCanvas.

 

Anyway I'm happy to talk this out over VC if you want to schedule a meeting. The parts of the system that have access to the DOM, ScriptValue, and all that stuff, are at a different abstraction layer.

Different than....?

Antoine

 

- E 

[Yuta Kitamura]

I agree with Elliott; that seems like a clear layering violation.

Our layering principle is:

core/ and module/ are for purely web platform features (accessible from IDLs). They can't touch Chromium stuff directly. If they need access to something in Chromium, they have to use it through platform/.

platform/ is an indirection layer that can access Chromium stuff.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMeTaZdsJG5-tOGJMoi6HeHPydL-1OPEOX15Q%3DKb3A8Mk0tjqA%40mail.gmail.com.

[Dana Jansens]

On Sun, Mar 13, 2016 at 10:36 PM, Yuta Kitamura <yu...@chromium.org> wrote:

I agree with Elliott; that seems like a clear layering violation.

Our layering principle is:

core/ and module/ are for purely web platform features (accessible from IDLs). They can't touch Chromium stuff directly. If they need access to something in Chromium, they have to use it through platform/.

platform/ is an indirection layer that can access Chromium stuff.

So IIUC you mean that platform/ should never return a type that isn't also defined in platform/? What about types defined in gfx:: or base::? 

Because code would continue to go through platform/ in order to get a gpu::gles2::GLES2Interface, which seems okay?

[Kenneth Russell]

On Mon, Mar 14, 2016 at 11:42 AM, Dana Jansens <dan...@google.com> wrote:

On Sun, Mar 13, 2016 at 10:36 PM, Yuta Kitamura <yu...@chromium.org> wrote:

I agree with Elliott; that seems like a clear layering violation.

Our layering principle is:

core/ and module/ are for purely web platform features (accessible from IDLs). They can't touch Chromium stuff directly. If they need access to something in Chromium, they have to use it through platform/.

platform/ is an indirection layer that can access Chromium stuff.

So IIUC you mean that platform/ should never return a type that isn't also defined in platform/? What about types defined in gfx:: or base::? 

It doesn't seem that that's the rule, since platform/graphics/GraphicsTypes.h includes Skia headers and exposes those types to modules/canvas2d/ . platform/graphics/Image.h additionally exposes SkCanvas to callers in Blink.

 

Because code would continue to go through platform/ in order to get a gpu::gles2::GLES2Interface, which seems okay?

That does seem OK, since yes, the callers would still call factory methods in platform/ to obtain gpu::gles2::GLES2Interface instances.

As Antoine's already pointed out, GLES2Interface is directly analogous to SkCanvas, which is already used by both modules/canvas2d as well as core/html/HTMLCanvasElement.cpp. WebGraphicsContext3D is a duplicate abstraction at this point. May we please proceed with removing it?

-Ken

[Kentaro Hara]

So IIUC you mean that platform/ should never return a type that isn't also defined in platform/? What about types defined in gfx:: or base::? 

 

Because code would continue to go through platform/ in order to get a gpu::gles2::GLES2Interface, which seems okay?

 

platform/ can access and return gfx:: and base:: types, and only (limited places of) platform/ should be able to do that. If core/ and modules/ want to use gfx:: and base::, they need to go through the platform/ as a glue layer.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMYvS2didfVfYC7P6b4Aop5MO3vdpwPfXAN36rGAiLdpb7g4MA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Dana Jansens]

On Mon, Mar 14, 2016 at 4:18 PM, Kentaro Hara <har...@chromium.org> wrote:

So IIUC you mean that platform/ should never return a type that isn't also defined in platform/? What about types defined in gfx:: or base::? 

 

Because code would continue to go through platform/ in order to get a gpu::gles2::GLES2Interface, which seems okay?

 

platform/ can access and return gfx:: and base:: types, and only (limited places of) platform/ should be able to do that. If core/ and modules/ want to use gfx:: and base::, they need to go through the platform/ as a glue layer.

Maybe all that is needed here is a type alias in platform?

namespace blink {
using GLES2Interface = gpu::gles2::GLES2Interface;
}

Is that what y'all are looking for here? (Ignoring the inconsistency with SkCanvas.) Or is that not enough?

[Elliott Sprehn]

I want the methods that deal with strings to be wrapped in helper functions that create WTF::String, or take them as arguments. The code needs this clean up in general, for example:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp&sq=package:chromium&l=1362&rcl=1457984318

that shouldn't be using name.utf8().data(), it should invoke a method in platform that takes a WTF::String, which then uses StringUTF8Adaptor to avoid the copy.

[Jeremy Roman]

On Mon, Mar 14, 2016 at 7:25 PM, 'Dana Jansens' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

On Mon, Mar 14, 2016 at 4:18 PM, Kentaro Hara <har...@chromium.org> wrote:

So IIUC you mean that platform/ should never return a type that isn't also defined in platform/? What about types defined in gfx:: or base::? 

 

Because code would continue to go through platform/ in order to get a gpu::gles2::GLES2Interface, which seems okay?

 

platform/ can access and return gfx:: and base:: types, and only (limited places of) platform/ should be able to do that. If core/ and modules/ want to use gfx:: and base::, they need to go through the platform/ as a glue layer.

Maybe all that is needed here is a type alias in platform?

namespace blink {
using GLES2Interface = gpu::gles2::GLES2Interface;
}

Is that what y'all are looking for here? (Ignoring the inconsistency with SkCanvas.) Or is that not enough?

For what it's worth, I'm not really sure what using type aliases in this way buys. IMHO, either there should be an abstraction layer (such that the underlying class can change without the callers changing), or there should not (and the underlying component can be used directly).

It seems to me that using type aliases both slightly obscures what the actual type is (making you redirect through a forwarding header), without actually protecting clients from changes in the interface.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAHtyhaRy_CmtEj2cwj%3Dyhb7P0cDJC_ANghfNc%3DVcMsgJ3pE_5g%40mail.gmail.com.

[Jeremy Roman]

On Mon, Mar 14, 2016 at 7:45 PM, Elliott Sprehn <esp...@chromium.org> wrote:

I want the methods that deal with strings to be wrapped in helper functions that create WTF::String, or take them as arguments. The code needs this clean up in general, for example:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp&sq=package:chromium&l=1362&rcl=1457984318

that shouldn't be using name.utf8().data(), it should invoke a method in platform that takes a WTF::String, which then uses StringUTF8Adaptor to avoid the copy.

I'm not sure I get this either: surely to avoid the copy, you'd need to plumb a StringPiece or equivalent all the way through, since you need to insert a null byte to adapt onto a C string API like the one gpu::gles2::GLES2Interface exposes. Barring that, there _is_ a copy.

It can probably be cheaper by using std::string or similar, rather than WTF::CString, but that seems orthogonal.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAO9Q3iLpnsbLoqi4kiRJ_GqeULsdvF9L-3e1AhPT1wx5BFiCug%40mail.gmail.com.

[Kenneth Russell]

The <10% of the functions in GLES2Interface that take raw C strings can be wrapped in helper functions (perhaps in a new GLES2Utils.h, like SkiaUtils.h?) that take a GLES2Interface* as well as the rest of the arguments in WTF::String form. However, it would still only be by convention that the raw underlying functions wouldn't be called. Will that be OK?

[Elliott Sprehn]

On Mon, Mar 14, 2016 at 5:18 PM, Kenneth Russell <k...@chromium.org> wrote:

The <10% of the functions in GLES2Interface that take raw C strings can be wrapped in helper functions (perhaps in a new GLES2Utils.h, like SkiaUtils.h?) that take a GLES2Interface* as well as the rest of the arguments in WTF::String form. However, it would still only be by convention that the raw underlying functions wouldn't be called. Will that be OK?

Yes that seems fine. If we see it coming up as a common issue we can add a PRESUBMIT that forbids those names outside platform/

- E 

[Kenneth Russell]

OK, thanks.