glfwGetProcAddress("WEBGL_draw_buffers") fails, why?

[Robert Goulet]

Hello,

I am trying to get a WebGL extension, namely WEBGL_draw_buffers, using glfwGetProcAddress and it always return nullptr. When I list all the available extensions of my browser I clearly see that WEBGL_draw_buffers is listed, and I am even able to run a demo on a web page that make use of it. So why glfwGetProcAddress always returns nullptr when used with Emscripten? Is this supposed to work?

Chrome JS console output this error:

bad name in getProcAddress: WEBGL_draw_buffers | WEBGL_draw_buffers

Also I am not sure if this is needed, but I made sure WebGL draft extensions are enabled in Chrome.

Or maybe glDrawBuffers is already mapped to WEBGL_draw_buffers when used in Emscripten? Can anyone confirm/deny this?

Thank you!

[Jukka Jylänki]

In Emscripten you have all the GL functions for core spec and extensions available already statically at compile-time without having to obtain function pointers. Calling the functions without obtaining pointers is preferred, since it gives better performance and is generally also simpler.

If you still want to call the function by querying the pointers e.g. in order to have a symmetric code path for both native and Emscripten, you should be able to. Perhaps we are missing support for that function/extension in glfwGetProcAddress? Try checking the src/library_gl.js and src/library_glfw.js on how they go through the route to obtain the function pointers to see what might be off there.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

Hmm, looks like we don't support any extensions in our getProcAddress code. It just supports functions. Should it support extensions? I'm not sure which docs to read regarding that.

- Alon

[Jukka Jylänki]

Oh wait, actually that sounds odd like Alon mentions: Are you calling getProcAddress with the name of an extension? That's unexpected, it's only supposed to be used for function names that an extension supports. Does glfwGetProcAddress("glDrawBuffers") work?

[Robert Goulet]

Yes perhaps you are right. If I use glDrawBuffers directly, it seems to work (no GL error reported), however glDrawBuffers is not supported by WebGL 1.0 specs. To use it, one must query for the extension WEBGL_draw_buffers.

So then I am wondering, what does Emscripten glDrawBuffers map to?

On Sunday, August 24, 2014 1:22:14 PM UTC-4, jj wrote:

Oh wait, actually that sounds odd like Alon mentions: Are you calling getProcAddress with the name of an extension? That's unexpected, it's only supposed to be used for function names that an extension supports. Does glfwGetProcAddress("glDrawBuffers") work?

2014-08-24 20:07 GMT+03:00 Alon Zakai <alon...@gmail.com>:

Hmm, looks like we don't support any extensions in our getProcAddress code. It just supports functions. Should it support extensions? I'm not sure which docs to read regarding that.

- Alon

On Sun, Aug 24, 2014 at 9:46 AM, Jukka Jylänki <juj...@gmail.com> wrote:

In Emscripten you have all the GL functions for core spec and extensions available already statically at compile-time without having to obtain function pointers. Calling the functions without obtaining pointers is preferred, since it gives better performance and is generally also simpler.

If you still want to call the function by querying the pointers e.g. in order to have a symmetric code path for both native and Emscripten, you should be able to. Perhaps we are missing support for that function/extension in glfwGetProcAddress? Try checking the src/library_gl.js and src/library_glfw.js on how they go through the route to obtain the function pointers to see what might be off there.

2014-08-24 19:39 GMT+03:00 Robert Goulet <robert.g...@gmail.com>:

Hello,

I am trying to get a WebGL extension, namely WEBGL_draw_buffers, using glfwGetProcAddress and it always return nullptr. When I list all the available extensions of my browser I clearly see that WEBGL_draw_buffers is listed, and I am even able to run a demo on a web page that make use of it. So why glfwGetProcAddress always returns nullptr when used with Emscripten? Is this supposed to work?

Chrome JS console output this error:

bad name in getProcAddress: WEBGL_draw_buffers | WEBGL_draw_buffers

Also I am not sure if this is needed, but I made sure WebGL draft extensions are enabled in Chrome.

Or maybe glDrawBuffers is already mapped to WEBGL_draw_buffers when used in Emscripten? Can anyone confirm/deny this?

Thank you!

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Jukka Jylänki]

In Emscripten glDrawBuffers is just glDrawBuffers. To query if that extension is supported, look for the string "WEBGL_draw_buffers" in glGetString(GL_EXTENSIONS);, e.g.

if (strstr(glGetString(GL_EXTENSIONS), "WEBGL_draw_buffers"))

{

   printf("WEBGL_draw_buffers is supported!\n");

   glDrawBuffers(...); // Now safe to call WEBGL_draw_buffers since we know it is supported.

}

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Robert Goulet]

It is supported by my browser. So basically I can just call glDrawBuffers and it should just work? Thank you.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark Callow]

On 2014/08/24 10:53, Robert Goulet wrote:

It is supported by my browser. So basically I can just call glDrawBuffers and it should just work? Thank you.

In WebGL, extensions must be enabled before use otherwise errors will be raised. WEBGL_draw_buffers is obviously a WebGL extension.

If Emscripten wishes to support use of WebGL extensions via glGetString & eglGetProcAddress, a call to glGetString(GL_EXTENSIONS) would have to both return the results of a call to ctx.getSupportedExtensions and it would have to enable every extension by calling ctx.getExtension and save the returned interfaces somewhere. It would also have to do a lot of other magic to convert the enums and functions of an extension to storedInterface.anextension.enum and storedInterface.anextension.func respectively.

I do not know what Emscripten is doing but enabling all extensions seems like unreasonable overhead for most apps as the number using all extensions can probably be counted on the fingers of one hand. Providing an equivalent to getExtension seems like a better idea, though I'm not sure how to present that in c.

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

[Alon Zakai]

Oh, so in normal non-WebGL GL, there isn't a method to enable an extension? They are all enabled by default? Then yes, it sounds like we need to add an option to enable an extension, emscripten_enable_webgl_ext(const char*) or such. I'm surprised we didn't run into this before. I think emscripten might already be enabling some extensions by default, that sounds familiar.

- Alon

--

You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Mark Callow]

On 2014/08/26 15:47, Alon Zakai wrote:

Oh, so in normal non-WebGL GL, there isn't a method to enable an extension?

Correct.

They are all enabled by default?

Yes.

Then yes, it sounds like we need to add an option to enable an extension, emscripten_enable_webgl_ext(const char*) or such. I'm surprised we didn't run into this before. I think emscripten might already be enabling some extensions by default, that sounds familiar.

Yes I think this option is needed.

In native OpenGL {,ES} the tokens are all defined in the .h files so can be used in code without any additional checks. Function pointers are also defined. To use an extension that does not add any functions, the application simply uses it, preferably checking for its existence first. For extensions that add functions, the app queries the function pointer values setting those into the existence function pointer variables.

In WebGL a call to getExtension, which is defined as "object? getExtension(DOMString name", returns an object which contains any constants or functions defined by the extension. This has to be reconciled with the native OpenGL way of doing things.

[Robert Goulet]

I'm getting a bit confused with all this.

Let's put it simple: I'm writing a WebGL application through Emscripten (not doing any Javascript code at all, pure C++), and I want to use the fairly new WEBGL_draw_buffers WebGL extension that is available on my browser's version.

In theory WEBGL_draw_buffers extension, when written in pure javascript, needs to be fetched with a call gl.getExtension('WEBGL_draw_buffers'), which returns a function allowing us to do the same as native OpenGL ES glDrawBuffers function.

But when I include the GL headers found in the Emscripten folder, I do get the glDrawBuffers function, and I can call it in my C++ code, no link error either upon Emscripten compilation. I tried it and it seems to work, since in my fragment shader I can write to gl_FragData[i] as opposed to the usual gl_FragColor. It does require me to add #extension GL_EXT_draw_buffers : require in my fragment shader at the top to make sure the extension is supported, but it all seems to work?

Can anyone explain me what is happening under the hood because I'm a bit confused. Perhaps we don't need any change to Emscripten at all as it is?

[Jukka Jylänki]

We do automatically enable WEBGL_draw_buffers and all other GL extension by default, to provide GLES2-esque treatise of this for native code. See https://github.com/kripken/emscripten/blob/master/src/library_gl.js#L852 . This occurs for code that initializes a GL extension via the emulated APIs like SDL, EGL, GLUT and GLEW. People haven't reported this to be a performance issue.

For HTML5/WebGL-aware context creation (emscripten_webgl_create_context: https://github.com/kripken/emscripten/blob/master/system/include/emscripten/html5.h#L366 ) , there is a field enableExtensionsByDefault ( https://github.com/kripken/emscripten/blob/master/system/include/emscripten/html5.h#L361 ), which allows choosing whether the GL extensions are default-enabled or whether the application would like to manually call emscripten_webgl_enable_extension ( https://github.com/kripken/emscripten/blob/master/system/include/emscripten/html5.h#L374 ) instead to track the extensions it wishes to enable.

Calling glGetString(GL_EXTENSIONS) does not enable extensions.

--

You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Jukka Jylänki]

Robert, the scenario you are describing sounds fine. You should not need to manually enable the extension, unless you opted to disable the default-enabling of extensions by explicitly calling emscripten_webgl_create_context with enableExtensionsByDefault set to false.

[Robert Goulet]

Thanks for confirming this! I create my context using glfwOpenWindow so most likely all extensions are enabled, and this is exactly what I want.

By the way, when is Emscripten GLFW support going to be upgraded to 3.x? The API is quite different, and it would be nice to be able to share the code between the Linux and the Emscripten build...

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.