Re:SwissGL: Swiss Army Knife for WebGL2
by synergy20 on Saturday February 25, 2023 @10:52PM
(#34942880)
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.
Re:SwissGL: Swiss Army Knife for WebGL2
by doodlesdev on Saturday February 25, 2023 @11:18PM
(#34942993)
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.
Re:SwissGL: Swiss Army Knife for WebGL2
by modeless on Sunday February 26, 2023 @01:04PM
(#34947665)
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.
Re:SwissGL: Swiss Army Knife for WebGL2
by modeless on Monday February 27, 2023 @12:05PM
(#34958915)
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.
Re:SwissGL: Swiss Army Knife for WebGL2
by kevingadd on Sunday February 26, 2023 @05:29AM
(#34944492)
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.
Re:SwissGL: Swiss Army Knife for WebGL2
by znah on Sunday February 26, 2023 @05:46AM
(#34944575)
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.
Re:SwissGL: Swiss Army Knife for WebGL2
by shaneos on Sunday February 26, 2023 @06:53AM
(#34944852)
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?
Re:SwissGL: Swiss Army Knife for WebGL2
by znah on Sunday February 26, 2023 @09:01AM
(#34945597)
Fixed, thanks for pointing! Undefined is only passed at the first frame, other frames receive current time in ms, according to requestAnimationFrame docs
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...
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.
So here we are without WebGPU being stable and without WebGL compute.
Chrome could have done it on top of Metal.
"At the time" was 2021.
Politics.
-- 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.
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