pyodide
pyodide copied to clipboard
Cannot create a WebGL2 context when using SDL
π Bug
I'm trying to run an application that uses SDL and OpenGL. I can get something to work with WebGL1 but not WebGL2
Javascript
var context = canvasElement.getContext("webgl2", contextAttributes);
C++
// Require OpenGL ES with major version 3
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, 0);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
auto window = SDL_CreateWindow("my window", 0, 0, 600, 400, window_flags);
auto glContext = SDL_GL_CreateContext((SDL_Window *)window);
if (glContext == nullptr)
{
std::string msg = std::string("Impl_CreateGlContext error: ") + SDL_GetError();
printf("%s\n", msg.c_str());
}
will fail with the message: "Could not create EGL context (call to eglCreateContext failed, reporting an error of EGL_BAD_CONFIG)"
However, using Webgl 1 does work (using canvasElement.getContext("webgl")and not setting SDL_GL_CONTEXT_MAJOR_VERSION in C++).
To Reproduce
Use the attached zip file, and unzip it into pyodide/packages.
daft_lib
βββ daft_lib_src
β βββ CMakeLists.txt # uses pybind11, links with -sUSE_SDL=2 sMAX_WEBGL_VERSION=2 sMIN_WEBGL_VERSION=2
β βββ _daft_lib_test.html # A simple test page, copy it into dist/
β βββ _daft_lib_webgl_test.html # A simple standalone test that ensures webgl2 is available (outside of pyiodide)
β βββ pyproject.toml
β βββ src
β βββ DaftLib
β β βββ DaftLib.cpp # provides `dummy_sdl_call` (will create a window and its opengl context)
β β βββ DaftLib.h
β βββ python_bindings
β βββ daft_lib
β β βββ __init__.py
β βββ module.cpp # provides a binding for `dummy_sdl_call`
βββ meta.yaml # repeats the flags -SUSE_SDL=2 -sMAX_WEBGL_VERSION=2 -sMIN_WEBGL_VERSION=2
Build it "in tree" with:
PYODIDE_PACKAGES="daft_lib" make
The HTML and C++ files are heavily commented and will produce lots of logs in order to help the diagnostic.
- Compile, and copy (or link) _daft_lib_test.html into pyodide/dist
- Launch a web server, and open _daft_lib_test.html with a browser
- Look at the JavaScript console.
Note: it is possible to switch to WebGL 1, by setting USE_WEBGL2=false in _daft_lib_test.html, and commenting out the #define USE_WEBGL2 in _daft_lib_test.html
Expected behavior
I hope it would be possible to use WebGL 2.
Environment
-
Pyodide Version: main branch, last commit: commit d32e376013d8977b66c6aa828042b1fee8047aea (origin/main, origin/HEAD) Author: Hood Chatham [email protected] Date: Tue Apr 23 15:01:33 2024 +0200
-
Browser version: Fails with Firefox and Chromium on Linux. Fails with Firefox and Safari on Mac OS
-
Any other relevant information: I already compiled numerous C++ / SDL programs to emscripten, using those same parameters, and it worked without issue.
I guess there might be something in the way emscripten is configured inside pyodide.
Additional context
I'm trying to port a library I created to pyodide: https://pthom.github.io/imgui_bundle/
ο»ΏLive emscripten demo here: https://traineq.org/ImGuiBundle/emscripten/bin/demo_imgui_bundle.html
Thanks for opening the issue! Unfortunately I'm not an SDL expert, so it's not clear to me exactly what's going on.
I did some quick search for the error in the Emscripten repository, and found that Emscripten only allows hard coded default config (code pointer, document). Maybe this can be related somehow, but I am not very sure...
Hello, thank you for your answer!
I think the information you gave me can hopefully point us in a better direction.
As far as I can understand, by reading the emscripten documentation, I think that OpenGL and EGL are two different graphics rendering targets.
- The page about EGL Is someone honest about the fact that the support for this API is lacking (and that in fact it is not common):
Somewhat disappointingly, EGL is not a self-sufficient complete solution for initializing GLES2 graphics rendering (on any platform, not just Emscripten) and overseeing various associated tasks. The specification is limited in its scope and lacks some features.
- The support for OpenGL seems more complete.
So the question becomes why does the application try to call eglCreateContext. I'll try to have a look at the call stack, to see if I can gather more information.
I opened a discussion about this subject in the Emscripten repository.
@ryanking13 : many thanks for your help.
After a long investigation, I understood that the issue was on my side: I had already created a context, on the javascript side; and as a consequence creation was failing on the C++ side.