OpenGL is dying

[jonathanhogg]

My current use of pyglet and moderngl was always a hack and needs to end. There are, thankfully, now some decent alternatives to investigate.

The top candidate for replacing OpenGL has to be WebGPU – which thankfully isn't just for the web. The rust-based wgpu-native library provides a multi-platform translation API that, importantly for me, maps to Metal in macOS. There appear to be solid Python bindings available for this library.

• https://www.w3.org/TR/webgpu/
• https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
• https://github.com/gfx-rs/wgpu-native
• https://github.com/pygfx/wgpu-py
• https://wgpu-py.readthedocs.io/en/stable/index.html

I'm still going to need a windowing layer and GLFW may be the thinnest/simplest cross-platform API for this that is supported by wgpu-py.

• https://www.glfw.org
• https://www.glfw.org/docs/latest/
• https://github.com/FlorianRhiem/pyGLFW

[jonathanhogg]

I've switched to GLFW, so at least a small part of this is now done.

[jonathanhogg]

Actually, a problem here is going to be that I am using the OpenGL back-end for skia. skia-python is pretty far behind mainline skia now, so there is an argument for replacing it, but I see no decent candidates and I'm not sure I have the appetite for creating my own…

[jonathanhogg]

As an alternative to switching away from OpenGL entirely it is worth considering switching to using ANGLE. This is a cross-platform implementation of OpenGL ES that translates to Metal on macOS. Now that I have Flitter compatible with OpenGL ES, I could use ANGLE as the back-end without a lot of rewriting.

Interestingly, I have sort of tested this on Apple Silicon macOS: the UTM virtualisation app allows running aarch64 Linux on macOS and this provides a para-virtualised GPU that uses ANGLE. Testing some GPU intensive Flitter examples with this shows them running over twice as fast under virtualisation than native.

GLFW has direct support for EGL using the glfw.CONTEXT_CREATION_API/glfw.EGL_CONTEXT_API hint and I've verified that this will load libEGL.dylib and libGLESv2.dylib libraries that I cribbed out of macOS Chrome.

The problem, however, is that moderngl uses glcontext and this uses the native OpenGL Framework on macOS and WGL on Windows. It does contain a Linux backend for EGL, however. The question is, can this be made to compile and function on macOS and Windows?

[jonathanhogg]

Had a quick look at changing glcontext and it might be possible.

An alternative is to switch to something else like zengl – although I am loath to make massive changes and zengl is a fairly different architecture. It at least looks like it ought to be easier to create an EGL loader. Although, it looks like it might be trying to use a function that isn't in OpenGL ES.

[jonathanhogg]

Have kinda gotten zengl working, but it wants to use glGetBufferSubData, which doesn't seem to be implemented in OpenGL ES.