HTML5/wasm support

[Zireael07]

I know it's noted as a wishlist item in the readme, so just making an official reminder that this is wanted :)

[pentaphobe]

Feel free to raise a pull request : )

[Zireael07]

I wish my Go-fu was that good :P

[unitoftime]

Hi,

Is there any interest in using something like goxjs as a base layer cross-platform gl and glfw library?

• https://github.com/goxjs/glfw
• https://github.com/goxjs/gl

I recently forked someone else's fork of these libraries which had WASM support and was able to port a 3D rendering experiment I was writing (full with 3D animations and shadow mapping). I was also playing around with tinygo and was able to build a WASM binary through tinygo which just rendered a basic triangle. Note: I don't really do mobile development, so I haven't tested any of the mobile features of the goxjs library. You can look at the changes I made in my fork, but most are fairly hacky just to get it to work

I looked a little into what it would take to use these goxjs bindings instead of the typical bindings for pixel:

1. GLHF would need to switch to the goxjs/gl bindings. Some of the gl calls will be modified
   a. Side note: One issue I see is the binder{} class which accepts uint32's regardless of the type of gl object being bound. In goxjs, they have types for each gl object (ie Buffer{}, Framebuffer{}, etc.). I think we can set up some casting to workaround this, though.
2. GLHF would have to implement the ContextWatcher interface that goxjs/glfw defines, This would basically force users of GLHF to also use goxjs/glfw (rather than whatever windowing library they want)
3. I haven't looked at pixel/pixelgl very much, but all glfw (looks like there's only 1 gl call) calls inside pixel would need to be migrated to the new bindings as well
4. Pixel documentation would need to be updated because not all glfw features are supported in WASM targets (ie you can't resize canvases and things like that). I would probably add some "This function will NOOP for these targets: WASM"
5. Pixel Readme update to explain how to build and use other targets
6. At least initially, we would operate on a cleaned up, feature-updated fork of the goxjs libraries. So there is some work there to clean that up.
7. tinygo builds won't support faiface/mainthread, so if we want that to work I think we need to have a 'tinygo-wasm' version of mainthread that just immediately calls the function. I think that regular wasm builds will work with mainthread, but I don't think they need it, so we could disable it there as well.

Pros:

• If everyone uses the same cross-platform gl bindings, then we can stabilize the library for anyone who wants to build some cool new golang rendering library (I'm looking at you, 3D)
• I think it'd be really cool if we could get pixel to compile (at least experimentally) with tinygo. There's something so satisfying about 300KB webgl builds

Cons:

• You migrate your library to rely on someone else's really old library, that we would have to fix up and maintain
• GLHF becomes dependent on windowing library
• Your GL calls become more like WebGL calls and less like desktop GL calls. There are also some troubles with missing WebGL features (such as CLAMP_TO_BORDER doesn't exist in WebGL)
• You are tied to whatever version of glfw, gl, webgl, etc that the goxjs [fork] is at

I figured I'd gauge your interest before I started any real work on this. I'm not an expert in OpenGL, but would be happy to do this migration, since I've done something similar in the past. There will likely be some periods of instability while the APIs settle. For the most part, I think desktop builds would remain fairly stable because most function calls just passthrough to the go-gl bindings.

Thoughts?