Multiple EGL Contexts

45 views
Skip to first unread message

Nils Schlemminger

unread,
Feb 25, 2020, 3:28:04 AM2/25/20
to emscripten-discuss
Hiho,

currently emscripten can only create one unique egl context that renders to a hard coded (id) canvas object.
I would like to generalize this approach to support multiple egl context on the same page rendering into different canvas objects.
As there is a lot of rework necessary I would like to ask if my approach (see below) would be accepted before spending the time to prepare a PR. And also to verify that I don't miss any showstopper. But I did a prototype and it looked like it is working.
Most of the work should be to generalize the context handling in library_egl.js. There the one and only context (and associated variables like error code, ...) is stored in the EGL variable. I would rework that we store a list (hashmap) of contexts together with the associated additional variables. eglCreateContext would then create the context and store it in the list and no longer returning a static magic number but a unique identifier to the device which serves as the index to the list.
To no longer hardcode the canvas I suggest providing the id of the canvas as part of the EGLDisplay (and defaulting back to the current id to keep compatibility with existing code).

Any thoughts on this proposal?

Kind Regards,
Nils

Jukka Jylänki

unread,
Feb 25, 2020, 6:42:44 AM2/25/20
to emscripte...@googlegroups.com
To bring the EGL implementation up to date, I started a rewrite of it
over to C/C++ so that it would be able to support multithreading and
OffscreenCanvas.

The work in progress branch was at
https://github.com/emscripten-core/emscripten/pull/5580. Since then I
have not been using EGL anymore, but directly use the Emscripten HTML5
API since it is a more direct 1:1 "webby" way to create WebGL
contexts.

While the branch still supported only a singleton context (see
https://github.com/emscripten-core/emscripten/compare/master...juj:egl_rewrite_in_c#diff-c7a64bb02e5f7b0658c1f4fce28d1186R13),
if you'd like to champion work on this area, I think it would be quite
straightforward to remove that global variable and replace it with a
`malloc()`ed structure.

Then, to add support for the user to choose the canvas, the EGL-esque
way would be to implement a platform specific version of
https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglCreatePlatformWindowSurface.xhtml
, which would allow passing a CSS canvas selector in the
'native_window' argument. That would enable connecting any canvas to a
context. This is similar to how EGL on Android binds to the native
window.

Anyway, just a thought. If you'd like to instead expand the current
library_egl.js code, then that is definitely also an option. Retaining
compatibility with the actual ID values from the old code is not
necessary, the actual values are an implementation detail that user
code should not be depending on their actual values.

ti 25. helmik. 2020 klo 10.28 Nils Schlemminger
(nils.sch...@achim-baden.net) kirjoitti:
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/81d1f213-559f-4a34-86d2-fd06e298f6bb%40googlegroups.com.

Nils Schlemminger

unread,
Mar 1, 2020, 5:32:36 AM3/1/20
to emscripten-discuss
Hi,

thanks for the awesome input. After a deeper look into you work I agree the right way would be to bring your C/C++ rework forward. But there is a lot to do.

Before you comment I never looked close to the html5 api but it seems to be awesome and solves most of my problems with much less effort so I will also go that route.

Thanks for your input.

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

Floh

unread,
Mar 1, 2020, 7:44:45 AM3/1/20
to emscripten-discuss
I basically came to the same conclusion, the web platform is different enough that the existing "native APIs" don't help much with managing the GL context, and it's better to use the emscripten helper functions, because they map much better to the specific behaviour of the underlying HTML5 APIs.

If you need some example code to get started here's my WebGL init code form the sokol_app.h header:


This also has a "canvas-tracking mode" where the WebGL canvas size is never changed by the emscripten code, but instead the canvas-size-changes from the webpage are tracked and forwarded to the application through the emscripten resize callback:


Very helpful for web pages where the WebGL canvas should stretch over the entire browser client rectangle (like in those demos: https://floooh.github.io/sokol-html5/).

Cheers,
-Floh.
Reply all
Reply to author
Forward
0 new messages