Hacker News Reader

Comment by dathinab | Hacker News Reader

> In fact it is so good I think it will replace Vulkan as well as normal OpenGL, and become just the standard way to draw, in any kind of software, from any programming language.

I fully agree with that, for a lot of use cases WebGL has everything you need, means it has the potential to become the cross platform graphics API OpenGL dreamed to be. And as a bonus you have a realistic way to run whatever app you are writing in the browser with WASM+WebGL.

I just think for AAA games Vulcan, Metal and DirectX12 will probably still be the way to go. But GUI libraries? Less highest end games? There is just no point once you can use WebGL everywhere. And then if you want to have a browser Demo you have a realistic chance to get it.

View on HN

> for a lot of use cases WebGL has everything you need

I think the original post refers to WebGPU

I can't tell if it's just a masterful troll implying web graphics history repeats itself.

it's a very embarrassing typo.

given that WebGL was known to use an "old" approach even before it was released and we don't have the problem with WebGPU I hope history doesn't repeats itself

History is repeating itself, there is no roadmap for mesh shaders or ray tracing.

So wait... do we now have a situation where the browser engine has converged with where the Java Virtual Machine was and provided a container to run write-once-run-anywhere desktop apps compiled to WASM?

All we need is the last mile -- progressive web apps -- to include better support for integration with desktop OSes and we have a way to take WASM apps and drag them to the desktop.

The up and coming languages for writing these WASM apps seem to be Go and Rust. Here's a Rust example:

https://www.egui.rs

WebGPU can be used outside of the browser through native libraries:

https://github.com/gfx-rs/wgpu

https://dawn.googlesource.com/dawn

(these are the libraries that are used in Firefox and Chrome to provide the WebGPU implementation, don't know if Apple/WebKit also has open-sourced theirs)

Some non-browser WASM runtimes also have WebGPU support already, but unfortunately only for offscreen rendering or compute tasks (e.g. for writing cross-platform windowed apps as WASM blobs, there's a window system glue layer missing).

> don't know if Apple/WebKit also has open-sourced theirs

https://github.com/WebKit/WebKit/tree/main/Source/WebGPU

I don’t know about WebGPU, but WebGL is missing some key performance features from OpenGL ES, like client-side buffers, pixel buffer objects, and MSAA render-to-texture frame buffers.

Client-side buffers are not a great idea. Pixel buffer objects and MSAA framebuffers exist in WebGL 2.

WebGL MSAA framebuffers exist, but require extra memory and an intermediate step compared to EXT_multisampled_render_to_texture https://registry.khronos.org/OpenGL/extensions/EXT/EXT_multi...

PBO support in WebGL lacks glMapBufferRange for non blocking read back.

Too bad that WebGPU builds on top of Vulkan, so the dependency (and incomplete support for some configurations) is still there.

WebGPU is designed to split the difference between Vulkan, DirectX 12 and Metal, it can be implemented on top of any of those.

In practice it'll only use Vulkan on Android and Linux, the main two implementations both default to DX12 on Windows even though they could technically use Vulkan there.

wgpu at least prefers Vulkan over DirectX 12 on Windows.

My mistake, they plan to use DX12 by default on Windows, but the DX12 backend isn't fully cooked yet so for now it defaults to Vulkan.

https://github.com/gfx-rs/wgpu/issues/2719

Reply on news.ycombinator.com