Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Here's a followup blogpost I wrote a few months later where I did a little experimental Typescript WebGL-wrapper (it was just one weekend, so not complete):

http://floooh.github.io/2016/10/24/altai.html

I think something like this could be used as a minimal wrapper for WebGPU, with WebGL2 and WebGL as fallback paths (shaders will be a problem though).

View on HN

That's neat, and I agree there's a lot of potential to learn and experiment with that approach.

I've done something similar with Go, it was a library [0] that exposed identical API in 3 situations: desktops, mobile, and browsers. It uses OpenGL 2.1 backend on desktop, OpenGL ES 2.0 on mobile, and WebGL 1.0 in browsers.

It worked really well and results in an extremely cross-platform graphics library. It was also a great way to learn about the few subtle differences between OpenGL ES and WebGL, and understand the kind of challenges they faced when designing the WebGL API.

[0] https://github.com/goxjs/gl

In the older post you mentioned one of the performance issues being that JS couldn't write directly to the GPU for security reasons and so a copy to the GPU would have to be done after the browser vetted things.

To my _very_ naive thinking, and if video RAM was plentiful, couldn't things be set up such that the JS runtime _could_ write to the GPU, but to a reserved section of video memory that wasn't directly executable? After being checked by the JS runtime, bytecode could be copied over to another area in video memory to be run. Would something like this work? If so, has this approach been tried by anyone?

You could use your oryol shader generator?

Reply on news.ycombinator.com