
Thoughts about a WebGL-Next (2016) - panic
https://floooh.github.io/2016/08/13/webgl-next.html
======
flohofwoe
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](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).

~~~
shurcooL
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](https://github.com/goxjs/gl)

------
iLoch
Security issues aside, why wouldn't we want "WebVulkan"? I suspect there would
be some interest from various parties in making a WebAssembly compatible cross
platform 3D library. Being able to create something with Unreal Engine, for
example, while targeting both web, mobile and desktop seems like it would be
incredibly powerful.

~~~
flohofwoe
Vulkan is a more like a driver-level API, an API to write other 3D-APIs with.
You need over a thousand lines of code to render a triangle. It doesn't
abstract the underlying GPU enough that you can have a single code path that
gives you best performance across GPU vendors (at least that was the state a
couple of months ago, I don't know if this has changed).

I think this is the wrong approach for a 3D API that should be usable by more
people than a very small group of highly specialised rendering engineers.
Metal is an API that fills that gap very well, it is easy to use _and_ is a
modern low-overhead API.

A proper modern 3D web API should be agnostic to the underlying native API (a
bit similar to how WebGL runs on top of D3D on Windows, but with much less
'conversion overhead' since most state is compiled into immutable objects).

~~~
exDM69
I am going to respectfully disagree with you here. Yes, Vulkan is a difficult
API to work with and it's not at all beginner friendly.

But simplicity and ease of use should not be guiding the decisions, the
emphasis should be on providing a way to run Unity, Unreal, and other engines
(new and old) on the Web.

Even if Vulkan is a difficult API to work with, a low level 3d API should be
available in a browser. It could be used as a building block to create
frameworks and engines that are easy to use.

Even WebGL is "too low level" for most application developers, which is why
three.js and other frameworks are popular.

~~~
cwyers
It's not about being too low-level for developers, it's about it being too
low-level for implementation. Vulkan is lower level than DX12 or Metal; you
can't implement it on top of those platform APIs, like ANGLE runs OpenGL ES on
top of a compatibility shim over DirectX or desktop OpenGL. A cross-platform
graphics API in the browser needs to be high-enough level to abstract over all
of Vulkan/DX12/Metal and provide a consistent interface so that developers
don't have to know which one their application is running on.

Either that, or in addition to WebVulkan you need WebDX12 and WebMetal.

~~~
erichocean
> _you can 't implement [Vulkan] on top of [DX12 or Metal]_

[http://lmgtfy.com/?q=vulkan+metal](http://lmgtfy.com/?q=vulkan+metal)

First result: _" MoltenVK is an implementation of Vulkan that runs on Apple's
Metal graphics framework on iOS and macOS."_

------
bobajeff
I can't wait to read flohofwoe's thoughts on WebGPU.

~~~
flohofwoe
I think it's great, hopefully SPIR-V will be used for shaders. I guess the
current use of MetalSL is a compromise to get the prototype up and running
fast. I think that MetalSL is pretty much the perfect shader language, but its
compiler shouldn't have to live in the browser.

~~~
glhaynes
Not too familiar with either - is MetalSL's compiler much more complicated
than SPIR-V's, such that it being in the browser would be onerous?

~~~
flohofwoe
MetalSL is basically a slightly stripped-down C++ with vector math datatypes
and some new annotation keywords, but I think it basically requires a complete
C++ compiler (Apple's MetalSL compiler is based on LLVM I think). SPIR-V is a
bytecode format with the idea that several shader languages could be compiled
into SPIR-V (hopefully also MetalSL).

------
HugoDaniel
Are there any plans to improve debugging ? It seems to be the elephant in the
room with this kind of tech

------
chj
Whatever it would be, I hope drawing a triangle is a one liner.

