SwissGL: Swiss Army Knife for WebGL2 | Hacker News Reader

SwissGL: Swiss Army Knife for WebGL2

github.com

147 pointslnyan18 comments

Author here. SwissGL is an experiment in minimal API design. I needed something that would simplify making things like https://znah.net/hexells or https://znah.net/lenia

I'm planning to switch to WebGPU once it's widely supported. I also think there's a chance for SwissGL.c, SwissGL.py and SwissGL.zig

This seems like a cool project. Is there a specific reason why you decided that allocating resources like textures should use the same function as performing rendering operations? It seems like it unnecessarily complicates reading the code and wouldn't be much worse if (for example) you did glsl.tex() or glsl.vbuf() etc when allocating resources and used glsl() for the rest. I was very confused when reading that part initially.

I wanted to avoid (in some cases) a separate initialization phase and unify resource allocation with rendering (because requirements may change and require reallocation). Take GameOfLife example (https://github.com/google/swissgl/blob/main/demo/GameOfLife....). It only has 'frame()' function which transparently resizes textures when needed.

The example in the README seems to be dividing “undefined” by 1000. Am I misunderstanding something, does that code truly generate the output shown somehow?

Fixed, thanks for pointing! Undefined is only passed at the first frame, other frames receive current time in ms, according to requestAnimationFrame docs

nice, I do not even know WebGL2 exists, and thought WebGPU is going to replace WebGL instead. WebGL2 looks well supported and very cool to use right now.

The biggest difference I spot between the two is that WebGL2 uses OpenGL ES 3 and WebGL uses OpenGL ES 2, but really other than supporting by default things that required extensions in WebGL I don't see much of an improvement. Also, it was released in Firefox in 2017 meaning it has been here for a long time already [0].

Interestingly enough projects such as Godot seem to until recently give preference to other APIs such as Vulkan and OpenGL ES 2 over OpenGL ES 3, not sure why though [1]. The biggest culprits seem to be mobile and Safari not implementing WebGL 2 until last year (what the hell Apple) [2].

I should note I'm not really familiar with neither APIs and only have a high-level understanding of WebGL.

[0]: https://hacks.mozilla.org/2017/01/webgl-2-lands-in-firefox/

[1]: https://godotengine.org/article/abandoning-gles3-vulkan-and-...

[2]: https://godotengine.org/article/about-godot4-vulkan-gles3-an...

WebGL 2 has a lot of stuff which is very nice if you are writing WebGL code, and some things that were just impossible in WebGL 1 even with extensions: https://webgl2fundamentals.org/webgl/lessons/webgl2-whats-ne...

There is very little reason to restrict yourself to WebGL 1 anymore, but many existing projects are still on WebGL 1 because Safari didn't support WebGL 2 when they were written.

WebGL 2 is going to be the best option for a long time. While WebGPU is in progress it will be many, many years before it is supported anywhere near as widely as WebGL 2.

It was also supposed to support GL ES compute shaders, developed by Intel, which Google refused to implement in name of WebGPU compute.

So here we are without WebGPU being stable and without WebGL compute.

Apple refused to implement GL compute shaders. Without that, Intel's code didn't work on macOS.

It isn't as if WebGL relies on GL on Windows.

Chrome could have done it on top of Metal.

Yes, Chrome could have rewritten the entire WebGL implementation to run on Metal. Maybe. Without support from Apple I'm not certain that WebGL 2 could have been fully implemented in a 100% compatible way over desktop Metal at the time. But it's not as though Google rejected a working implementation for no good reason.

And now WebGL 2.0 on Safari is actually implemented on top of Metal, with help of Chrome team.

"At the time" was 2021.

Politics.

"At the time" was 2019 actually. Back then it wasn't even clear if Apple would ever implement WebGL 2 at all.

https://bugs.chromium.org/p/chromium/issues/detail?id=113199...

-- Sep 24, 2020,

https://registry.khronos.org/webgl/specs/latest/2.0-compute/

-- Last update, regarding deprecation, 31 March 2021

Hence 2021.

Same reasoning could be applied to Microsoft and Sony Playstation browsers, where neither of them support GL.

Fact is that after all these years, WebGPU still isn't here as stable version that one can rely on, and even then it is only a MVP with an incompatible shader language.

The code wasn't removed immediately when the decision was made so that people could continue prototyping compute shaders before WebGPU was available to test on. Game console browsers are completely irrelevant as their market share is so miniscule it's not even visible on most tracking sites.

Actually I believe apple and windows use a library to convert gles3/webgl2 to metal and dx.

Any chance of typescript version?

Reply on news.ycombinator.com