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.
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.
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.
-- 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.
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