I'm not too familiar with the internal details, so take it with a grain of
salt :)
First, WASM has a function import table which maps Javascript function
names and a 'call signature' to a function index (a number, basically).
When compiling with debug info (-g), one can inspect this import table in
Firefox, the import entry for glClearColor looks like this for instance:
(import "env" "_glClearColor" (func $_glClearColor (;61;) (param f64 f64
f64 f64)))
This basically says that there's a Javascript function which takes 4
float64 arguments. There's a WASM 'call' instruction, for instance:
get_local $var188
f64.promote/f32
get_local $var189
f64.promote/f32
get_local $var190
f64.promote/f32
get_local $var185
f64.promote/f32
call $_glClearColor
This is basically a foreign-function-interface call which puts four float64
values on the "argument stack" and calls the external _glClearColor
Javascript function.
This WASM code is generated from the C code in here:
https://github.com/emscripten-core/emscripten/blob/incoming/system/lib/gl/webgl1.c
...now on the Javascript side, it's a bit more non-obvious, the interesting
bits are in here:
https://github.com/emscripten-core/emscripten/blob/incoming/src/library_webgl.js
glClearColor is treated as a simple "pass-through function" because it just
has 4 floating point parameters, no GL object handles that need to be
mapped to Javascript objects. The 'forwarding code' for this seems to be
code-generated here:
https://github.com/emscripten-core/emscripten/blob/b9499bd139f720349844d0af5fd0394df1b78dd9/src/library_webgl.js#L3507-L3537
But again, debug mode to the rescue, the generated JS code can be inspected
in the browser by searching in the application's .js file:
function _glClearColor(x0, x1, x2, x3) { GLctx['clearColor'](x0, x1, x2,
x3) }
GLctx is the WebGL context, so that's the same as:
function _glClearColor(x0, x1, x2, x3) { GLctx.clearColor(x0, x1, x2, x3); }
(I'm not sure why the function code isn't generated like this, but I guess
there's a reason).
So basically:
- for each GL call, a small JS proxy function exists which forwards the
call to the WebGL context object
- each Javascript proxy function is made available to WASM code through the
imports-table
- WASM code calls the JS proxy function though a 'foreign function
interface' implemented by the WASM runtime in the browser
Cheers,
-Floh
On Friday, 5 April 2019 22:47:32 UTC+2, Rick Battagline wrote:
>
> Thanks Floh,
>
> I've been looking through that code. I'm still trying to figure out how
> exactly the calls go back and forth. It kind of looks to me like there is
> an array of calls that somehow get triggered, but I'm not completely sure
> that's the way to work. How exactly do WebAssembly calls to OpenGL get
> translated into JavaScript WebGL calls? I'm still rather unclear on that.
>
> Thanks again,
> Rick
>
> On Wednesday, April 3, 2019 at 5:13:35 AM UTC-6, Floh wrote:
>>
>> It seems the GL wrapper implementation has changed a lot quite recently.
>> From my (external) pov it seems to work like this now:
>>
>> There's a C part here:
>> https://github.com/emscripten-core/emscripten/tree/incoming/system/lib/gl
>>
>> ...which looks like it's just a library of slim C proxy functions which
>> forward the GL calls to the Javascript side for different scenarios (e.g.
>> GL code running on the main thread or not).
>>
>> The actually interesting stuff happens in JS code here:
>>
>>
>> https://github.com/emscripten-core/emscripten/blob/incoming/src/library_webgl.js
>>
>> https://github.com/emscripten-core/emscripten/blob/incoming/src/library_webgl2.js
>>
>> https://github.com/emscripten-core/emscripten/blob/incoming/src/library_glemu.js
>>
>> This basically emulates GLES2, GLES3 or desktop GL on top of WebGL or
>> WebGL2 (at the very least this must map GL object handles which are
>> GLuint's in C code to Javascript objects, but there's a lot more stuff
>> going on which I haven't looked at in detail).
>>
>> A while ago all this was in a single library_gl.js source file, but I
>> think conceptually this did the same.
>>
>> I have no clue about the SDL vs GL problems you're seeing unfortunately,
>> my code uses the emscripten_webgl_*() functions for context setup.
>>
>> Cheers!
>>
>> On Tuesday, 2 April 2019 22:59:39 UTC+2, Rick Battagline wrote:
>>>
>>> Hi,
>>>
>>> I've been having some problems mixing SDL and OpenGL. Changing the
>>> shaders using calls to OpenGL seems to be creating problems with SDL. I'm
>>> trying to figure out how the Emscripten port of OpenGL works. Looking
>>> through some of the glue code it looks like there is some webgl code that I
>>> assume is being called from the WebAssembly.
>>>
>>> Does anyone know how the Emscripten implementation of OpenGL works?
>>>
>>> Where can I find the code for the OpenGL Emscripten implementation?
>>>
>>> Thanks
>>>
>>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
