7 ms·

OpenGL to WASM, learning from my mistakes

84 points by uds5501 2y ago

Sincere6066 2y ago
OpenGL is a graphics api and WASM is a binary code format isn't it?
deleted 2y ago
[deleted]
bobajeff 2y ago
This 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.
- theophinetheo 2y ago
  Same here, happened on my computer.
- rossant 2y ago
  Same. Consider putting the demo in a separate page.
linwangg 2y ago
[dead]
avianlyric 2y ago
This 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 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.
- modeless 2y ago
  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.
  - shooly 2y ago
    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 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.
    - modeless 2y ago
      I don't have internal knowledge of Apple's implementation but it could potentially be layered on top of Metal for Apple Silicon (probably not for Intel) though if so it probably uses internal-only capabilities not exposed to Metal users. 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.
  - LoganDark 2y ago
    > WebGL is not deprecated, and uses the ANGLE library *on Chromium!!! Firefox and WebKit do not use ANGLE for rendering.
    - modeless 2y ago
      This is false. Source: I added WebGL 2 support to WebKit using ANGLE, with Apple's help (they made ANGLE's Metal backend). Firefox uses ANGLE on every platform for shader translation, and on some platforms it uses ANGLE for the entire API (on others it has a custom OpenGL to WebGL translation layer).
Thaxll 2y ago
This page is extremely slow on a powerful desktop CPU.
- glitchc 2y ago
  Hmm, it loaded instantly on my machine.
  - 01HNNWZ0MV43FF 2y ago
    I'm on a 2015-era Intel Core CPU and iGPU and yeah the page stutters badly when I scroll near the WebGL canvas
  - XCSme 2y ago
    It loads fast, but it's slow and stutters (3090 24GB + 12c/24t 5900X + 128GB RAM), so it's not my PC...
rddbs 2y ago
Tangential question for c++ devs: How would this even compile before the author fixed the Sphere* typo in the vector?
- grg0 2y ago
  It really won't. The only reason I could think of is if there were a Sphere(Sphere*) constructor, which would be weird, and is also not the case [1]. There is also no reason to use a vector<Sphere*> since Sphere is not part of an inheritance tree; a vector<Sphere> would've done just fine removing the calls to 'new' in that blog post. Overall, I think this post is on the low end of the quality spectrum. I think the author is a bit confused about things, like they've been doing JS and picked up C++ only recently. Nothing bad about it, but I would do some more reading before posting much of anything. [1] https://github.com/uds5501/multiple-spheres/blob/master/include/shapes/Sphere.h https://github.com/uds5501/multiple-spheres/blob/master/incl...
XCSme 2y ago
I didn't get the point of the article (it starts saying that there were some performance limitations, not mentioning exact what, then something about porting, then some debugging of basic API calls), plus the page is non-responsive at times from the included demo I assume.
waych 2y ago
Wow, 89MB of sphere "data". Why not just use a RNG?
LoganDark 2y ago
> I believe anyone can learn this tech with the presence of resource and LLMs Is this really the world we live in now, where people think you need LLMs for learning?

84 points by uds5501 2y ago

Sincere6066 2y ago

OpenGL is a graphics api and WASM is a binary code format isn't it?

deleted 2y ago

[deleted]

bobajeff 2y ago

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

theophinetheo 2y ago
Same here, happened on my computer.
rossant 2y ago
Same. Consider putting the demo in a separate page.

linwangg 2y ago

[dead]

avianlyric 2y ago

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

modeless 2y ago
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.
- shooly 2y ago
  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 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.
  - modeless 2y ago
    I don't have internal knowledge of Apple's implementation but it could potentially be layered on top of Metal for Apple Silicon (probably not for Intel) though if so it probably uses internal-only capabilities not exposed to Metal users. 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.
- LoganDark 2y ago
  > WebGL is not deprecated, and uses the ANGLE library *on Chromium!!! Firefox and WebKit do not use ANGLE for rendering.
  - modeless 2y ago
    This is false. Source: I added WebGL 2 support to WebKit using ANGLE, with Apple's help (they made ANGLE's Metal backend). Firefox uses ANGLE on every platform for shader translation, and on some platforms it uses ANGLE for the entire API (on others it has a custom OpenGL to WebGL translation layer).

Thaxll 2y ago

This page is extremely slow on a powerful desktop CPU.

glitchc 2y ago
Hmm, it loaded instantly on my machine.
- 01HNNWZ0MV43FF 2y ago
  I'm on a 2015-era Intel Core CPU and iGPU and yeah the page stutters badly when I scroll near the WebGL canvas
- XCSme 2y ago
  It loads fast, but it's slow and stutters (3090 24GB + 12c/24t 5900X + 128GB RAM), so it's not my PC...

rddbs 2y ago

Tangential question for c++ devs: How would this even compile before the author fixed the Sphere* typo in the vector?

grg0 2y ago
It really won't. The only reason I could think of is if there were a Sphere(Sphere*) constructor, which would be weird, and is also not the case [1]. There is also no reason to use a vector<Sphere*> since Sphere is not part of an inheritance tree; a vector<Sphere> would've done just fine removing the calls to 'new' in that blog post. Overall, I think this post is on the low end of the quality spectrum. I think the author is a bit confused about things, like they've been doing JS and picked up C++ only recently. Nothing bad about it, but I would do some more reading before posting much of anything. [1] https://github.com/uds5501/multiple-spheres/blob/master/include/shapes/Sphere.h https://github.com/uds5501/multiple-spheres/blob/master/incl...

XCSme 2y ago

I didn't get the point of the article (it starts saying that there were some performance limitations, not mentioning exact what, then something about porting, then some debugging of basic API calls), plus the page is non-responsive at times from the included demo I assume.

waych 2y ago

Wow, 89MB of sphere "data". Why not just use a RNG?

LoganDark 2y ago

> I believe anyone can learn this tech with the presence of resource and LLMs Is this really the world we live in now, where people think you need LLMs for learning?