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: https://github.com/floooh/sokol/blob/7233ab514a18e5f10da5ad3fddde82c98a604508/sokol_app.h#L2770 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: https://github.com/floooh/sokol/blob/7233ab514a18e5f10da5ad3fddde82c98a604508/sokol_app.h#L2316 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. On Sunday, 1 March 2020 11:32:36 UTC+1, Nils Schlemminger wrote: > > 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 > > On Tuesday, February 25, 2020 at 12:42:44 PM UTC+1, jj wrote: >> >> 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/5b99e9c2-8856-44b7-836d-97070157c670%40googlegroups.com.
