[HN Gopher] OpenGL to WASM, learning from my mistakes
___________________________________________________________________
OpenGL to WASM, learning from my mistakes
Author : uds5501
Score : 66 points
Date : 2025-03-01 13:24 UTC (9 hours ago)
(HTM) web link (uds5501.github.io)
(TXT) w3m dump (uds5501.github.io)
| bobajeff wrote:
| 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 wrote:
| Same here, happened on my computer.
| rossant wrote:
| Same. Consider putting the demo in a separate page.
| avianlyric wrote:
| 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 wrote:
| 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 wrote:
| 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 the author is doing.
| modeless wrote:
| 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.
| beepbooptheory wrote:
| Not only that, but the "lessons" learned here don't seem to
| have anything to do with the specific fact its an emscripten
| port anyway, just like general webgl troubleshooting.
|
| To be fair, its very explicit that this isn't really a typical
| writeup. The whole article is apparently just about giving you
| answers that the AI didn't give them:
|
| > I believe anyone can learn this tech with the presence of
| resource and LLMs, however, It's worth to mention the mistakes
| that your cursor IDE might not be able to figure out after a
| while of composition to and fro.
| miningape wrote:
| As soon as I read that line I stopped reading, I really don't
| care what mistakes an AI made - it doesn't understand what
| it's doing so the mistakes are arbitrary, and relate more to
| it's inability to understand anything than some fundamental
| difficulty in the topic.
|
| Just look at the mistakes in the article: an off-by-one error
| with the lines of code for rendering, and a pointer bug that
| prevents the program from compiling. These are the kinds of
| mistakes you make in your first few weeks of programming, and
| don't have much to do with the underlying topic of rendering
| with a GPU - it could have just as easily been written about
| implementing a database, implementing an operating system:
| anything of sufficient complexity.
|
| Not to begrudge the author but this shows more about his
| faith in AI than anything related to GPU rendering.
| Thaxll wrote:
| This page is extremely slow on a powerful desktop CPU.
| glitchc wrote:
| Hmm, it loaded instantly on my machine.
| 01HNNWZ0MV43FF wrote:
| 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 wrote:
| It loads fast, but it's slow and stutters (3090 24GB +
| 12c/24t 5900X + 128GB RAM), so it's not my PC...
| rddbs wrote:
| Tangential question for c++ devs: How would this even compile
| before the author fixed the Sphere* typo in the vector?
| grg0 wrote:
| 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/incl...
| XCSme wrote:
| 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.
| Sincere6066 wrote:
| OpenGL is a graphics api and WASM is a binary code format isn't
| it?
| waych wrote:
| Wow, 89MB of sphere "data". Why not just use a RNG?
___________________________________________________________________
(page generated 2025-03-01 23:00 UTC)