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 ([email protected]) kirjoitti: > > 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 > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/81d1f213-559f-4a34-86d2-fd06e298f6bb%40googlegroups.com. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-3CPSXqMbJHu0w%3DrKCHb7mC5x70Lj9GVjqDU4tJCU4e5w%40mail.gmail.com.
