OpenGL to WASM, learning from my mistakes
uds5501.github.io
OpenGL to WASM, learning from my mistakes
1–10 of 28 posts
Re: OpenGL to WASM, learning from my mistakes
#2Re: OpenGL to WASM, learning from my mistakes
#3Re: OpenGL to WASM, learning from my mistakes
#4This page must be loading a webgl scene since it's making my poor mobile browser gradually unresponsive to my scrolling. Thankfully closed to page before it was to late.
Re: OpenGL to WASM, learning from my mistakes
#5Re: OpenGL to WASM, learning from my mistakes
#6> maybe it’s time to port this to the web and not my machine be a blocker for the demo.
So their solution is to port from C++ and OpenGL to WASM and WebGL. Last I checked WASM and WebGL all ran on the local machine, how on earth would porting to WebGL and WASM allow the author to make their “machine be a blocker for the demo”. They’re not changing any of the hardware involved, and they’re barely changing the technologies involved.
Re: OpenGL to WASM, learning from my mistakes
#7This is a very confusing article that doesn’t make much sense to me. The authors runs into performance limits on their laptop and states > maybe it’s time to port this to the web and not my machine be a blocker for the demo. So their solution is to port from C++ and OpenGL to WASM and WebGL. Last I checked WASM and WebGL all ran on the local machine, how on earth would porting to WebGL and WASM allow the author to ma…
Re: OpenGL to WASM, learning from my mistakes
#8This page must be loading a webgl scene since it's making my poor mobile browser gradually unresponsive to my scrolling. Thankfully closed to page before it was to late.
Re: OpenGL to WASM, learning from my mistakes
#9This is a very confusing article that doesn’t make much sense to me. The authors runs into performance limits on their laptop and states > maybe it’s time to port this to the web and not my machine be a blocker for the demo. So their solution is to port from C++ and OpenGL to WASM and WebGL. Last I checked WASM and WebGL all ran on the local machine, how on earth would porting to WebGL and WASM allow the author to ma…
WebGL runs on the same machine but uses a very different path to the GPU. On Mac, OpenGL is deprecated and the implementation is very outdated and feature poor. WebGL is not deprecated, and uses the ANGLE library to run on top of Metal.
ANGLE on macOS supports OpenGL ES 3.0 when running using Metal backend (source: https://github.com/google/angle), whereas macOS natively supports Core 4.1.
And from my experience, there is basically no difference in performance between Apple's implementation and ANGLE, especially for simple things like what the author is doing.
Re: OpenGL to WASM, learning from my mistakes
#10Earlier quoted context omitted.
WebGL runs on the same machine but uses a very different path to the GPU. On Mac, OpenGL is deprecated and the implementation is very outdated and feature poor. WebGL is not deprecated, and uses the ANGLE library to run on top of Metal.
From what I know, OpenGL on macOS is internally implemented using Metal and supports more features than ANGLE. ANGLE on macOS supports OpenGL ES 3.0 when running using Metal backend (source: https://github.com/google/angle ), whereas macOS natively supports Core 4.1. And from my experience, there is basically no difference in performance between Apple's implementation and ANGLE, especially for simple things like what…
OpenGL ES 3.0 is newer than OpenGL 4.1. The feature set is broadly very similar. Native macOS OpenGL is a backwards compatibility feature and not intended for new development. Lack of KHR_debug and general bugginess makes it a poor choice for learning OpenGL or deploying software on. On the other hand, WebGL is currently supported and extensively tested, with much better validation and error messages and much (much, much) better cross platform compatibility.