Does the WebAssembly community really need to reinvent the wheel and create yet another set of new platform APIs?
I'm sure over time, and if desired, WASI will get a set of higher level platform-wrapper APIs for rendering, audio, input and networking, but the requirements are somewhat different from traditional "native" APIs, for instance, compatibility with web APIs is useful. So we'll probably see the WebGPU API for 3D rendering, instead of Vulkan, D3D12 or Metal.
Unfortunately, we now have "diet graphics", which consists of stuffing WebKit into C++ and calling it a day [1], so, looking forward to where that goes! [2]
[0] https://www.reddit.com/r/cpp/comments/89q6wr/sg13_2d_graphic...
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p110...
[2] Hopefully into the bin.
Because if you "blit a bunch of pixels to the screen", you don't care about performance regardless.
PS: I think there's some confusion about WASM running in browsers, vs WASM running on top of WASI. WASI is all about running WASM outside the browser: https://wasi.dev/
That this is not a good way for doing more complex rendering tasks seems quite obvious (e.g. in the long run this cannot be the only API for covering all sorts of rendering, but it happens to be a good sweet spot for getting anything on screen at all, and not having to deal with an overly complex rendering API just to get some 2D image data rendered).
Are we really going back 30 years?
For 3D rendering, WebGPU would be the better option to support in WASI because it has standalone native implementations:
https://dawn.googlesource.com/dawn
https://github.com/gfx-rs/wgpu
But for blitting CPU-generated 2D image data to the screen WebGPU is also sort of overkill (of course it would be possible to create a much simplified wrapper library in WASM).
Then there is WebGL and OpenGL ES, widely used everywhere too.
So, no, it is not going anywhere. In fact, Khronos themselves have said so.
Also I think it's obvious but I'll say it anyway; it's not up to khronos it's up to developers. It doesn't matter if they continue to support OpenGL if developers move to some combination of dx11/12, Vulkan, and Metal.
WebGL and OpenGL ES aren't OpenGL. Their uptake or lack thereof in other arenas is orthogonal to whether people are moving away from OpenGL for game development.
WebGL and OpenGL ES are pretty much OpenGL. Formally they are different standards, but they are based all in OpenGL: if you know one, you know the others pretty well, which is what is important for developers as you agree in the second paragraph.
If it were true that lots of games were picking OpenGL, why is it so hard to make a long list of them? It's easy to make such a list for vulkan.
They haven't supported OpenGL for years anyway, so the fact they deprecate it now is irrelevant.
In any case, abstraction layers for macOS already exist.
And, going by your definition, if Apple only allows Metal, then no API will be cross-platform ever anyway.
---
* Removal of components which have been replaced by new standalone tools:
* FrameAnalysis - use https://github.com/GPUOpen-Tools/Radeon-GPUProfiler
---
...that Radeon-GPUProfiler is that tool which has only D3D12 and Vulkan support.
Look around for AMD's OpenGL activity more recently, there's not much, which isn't surprising because they've been lagging behind NVIDIA with their GL drivers since forever. I bet they're eager to close that chapter.
NVIDIA seems more committed to GL still, but without having all GPU vendors on board to continue supporting OpenGL, Khronos won't be able to do much to keep it alive.
That is not news, and that has nothing to do with the state of OpenGL.
Please, stop spreading misinformation about OpenGL.
Please don't make things up. OpenGL 4.6 was released in July 2017. According to Wikipedia, modern AMD and NVIDIA cards both gained driver support for it in April 2018. Intel drivers have support since May 2019.
Just leave it to die.
Dawn and wgpu are also collaborating on a common set of native headers (https://github.com/webgpu-native/webgpu-headers) to make it easy to switch between implementations.
Regardless it's the closest portable solution at the moment, and it will continue to add capabilities. The WebGPU CG has already had public meetings with Khronos to talk about running WebGPU on top of Vulkan, and running Vulkan Portability on top of WebGPU. So I think there's a lot of interest in making WebGPU succeed on both web and native targets.
If WebGPU ends up being as castrated as WebGL, then we either keep using OpenGL, or change to modern middleware engines (which is what most are doing), with the added benefit that they make the actual 3D API less relevant, it is just a checkbox.
You cannot create a window or handle input with OpenGL.
That's why Godot is moving to Vulkan, that can also run on Metal: https://godotengine.org/article/retrospective-and-future
For Godot game developers, this will not be visible in any way, it's under the hood change to engine.
For other apps, there is in progress development to run full OpenGL on top of Vulkan with Zink. There is a blogpost about it here: https://www.collabora.com/news-and-blog/blog/2018/10/31/intr...
There is also a talk about it at The X.Org Developer's Conference 2019-10-02 here, for example Blender seems to work already: https://youtu.be/rV0P1ChE_5o?t=3970
All conference recordings are listed at conference website: https://xdc2019.x.org/
Today, with Vulkan and soon WebGPU available, there really is very little reason to hang on to OpenGL for anything but legacy.
OpenGL is not simple if you want to actually do useful things with it.
SDL? Has ports for more obscure platforms, too
SDL_Window *window;
SDL_Renderer *renderer;
SDL_CreateWindowAndRenderer(800, 600, 0, &window, &renderer);
SDL_RenderDrawPoint(renderer, 400, 300); //Renders on middle of screen.
SDL_RenderPresent(renderer);
Personally I think Web compatibility is so useful that wasm off the Web should use Web APIs, instead of the direction WASI is going.
WASI is an effort to create a new OS API layer from scratch, without the baggage of POSIX or the Web or such. That's definitely interesting, and may be a big deal in the long run, but it has risks (it will take a lot longer, in particular) and it has downsides for the Web (which is personally the platform I care most about).
The article linked here is an advertisement for a startup.
https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al.... "secure-by-default foundations for native development that are portable and scalable."
Likewise, they wouldn't "forget" the formats that already had support for languages like C when talking about what is "new" with WebAssembly.
That can be supported in the source language.
Solaris, iOS and future Android versions take advantage of their existence.
The fact remain that wasm module have a very well defined behavior when embedded in other applications and can be embedded in a portable way.
What you're saying is that every vendor shipped their software with source code and only used cross platform APIs. Is that right?
That is how it has always been done and is still done.
Yes, you can do it differently with an IL, but that isn't new either (Java, .NET, etc.).
Just like with TIMI, MSIL, EM, ADF, TendDRA, PNaCL among others.
> What you're saying is that every vendor shipped their software with source code and only used cross platform APIs. Is that right?
Rather that this is nothing new, and the formats listed above, already offered the same capabilities, without the same marketing.
https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/
And it doesn't offer any significant security improvements, in spite of its marketing, compiling Heartbleed into WASM is still possible.
I don't really see the point of using WebAssembly (or any other bytecode format) outside the browser, though. It just seems like a way to throw away performance for no benefit.
Mainframes and midrange computers have used bytecode formats since the early 60's as hardware independence mechanism, where you AOT compile at installation time, or have an hardware interpreter implemented as part of a micro-coded CPU.
It has allowed those kind of computers to advance their hardware to modern times, while keeping the applications unchanged.
The same idea is widely used on embedded platforms, as it gives OEMs flexibility designing hardware, while reducing software development costs even further.
- The original 32-bit x86 implementation fundamentally required it because, due to how it used %ss, a crash in the sandboxed code would crash the whole process. [1] Avoiding that issue would have required a different model that had performance overhead (and was more complicated). Ironically, the 64-bit version had no such requirement, but by then NaCl's design was already well-established.
- AFAIK it was originally developed separately from Chrome, so there was less motivation to deeply integrate it with JS.
- It was apparently conceived as a replacement for plugins (originally using NPAPI, before PPAPI was invented), which Chrome had run in a separate process anyway.
But WebAssembly is designed to run in the same process as DOM/JS, giving it two key advantages: it can reuse Web APIs rather than needing a whole separate set of APIs (PPAPI), and it can directly call and be called from JS. Both make life easier for developers; reusing web APIs also makes life easier for implementers.
The second key difference is that NaCl leaks much more information about the native environment than WebAssembly. Even with PNaCl, the native text segment, the native stack, and certain bits of implementation code were all accessible within the sandboxed address space. If you were up to shenanigans, you could even do things like jump into the middle of a native function, completely breaking the portability abstraction. Was that a problem? I don't know. It was conceptually secure; you couldn't break out of the sandbox without finding a vulnerability, just like WebAssembly. But it was a lot less isolated. In contrast, WebAssembly makes none of those things accessible and enforces full control flow integrity. You can't even tell which architecture you're running on, aside from indirect observations by benchmarking instructions or checking for memory ordering violations.
That difference is certainly responsible for some of the performance gap between NaCl and WebAssembly. Is it responsible for all of it? I don't know. I don't even know how big the gap is in the first place; the PDFTron benchmark makes it look major, but I haven't seen any other benchmarks, and I'm not sure if anyone has investigated what exactly is causing the overhead in the PDFTron benchmark, especially since the code isn't open source.
[1] https://static.googleusercontent.com/media/research.google.c...
You say that wasm is a political "bastard" born out of mozilla refusal for PNaCL. I disagree, but it is a way of looking at history.
But then my stance would be that to satisfy the w in wasm it Needs to be a political chimera, the whole web is predicated on the model of vendors fighting political and technical battles over standard. PNaCL lost that battle, Java lost miserably that battle, every other portable assembly ever never even participated.
Are you criticizing wasm or the open web?
Every other GUI libraries are order of magnitude inferiors except if you just want to look like windows default utilities.
Serious question: what is the common electron app business case?
Being able to run as a desktop app as well as in a browser?
The reuse developers part I suppose could be achieved with QtQuick since QML is javascript based, but beyond the language, not that much else translates and you can’t completely get away from C++ for anything non-trivial, so it’s not really an electron competitor.
Easy portability (not perfect) between all major platform
That is certainly true.
But I was answering to
> The same as from using Electron, but a step further: less overhead from unneeded browser features, ability to lock the user into a kiosk/fullscreen mode, while most of the code is still reusable.
namely _Desktop applications_
Wasmer claim is
> Use the tools you know and the languages you love. Compile everything to WebAssembly. Run it on any OS or embed it into other languages.
There's no browser involved here, just compile once, run everywhere
I have the feeling I already heard it...
>I have the feeling I already heard it...
If you are referring to java then something to note is
> Use the tools you know and the languages you love.
> Compile everything to WebAssembly.
> [..] embed it into other languages.
Which to my understanding apply only marginally to java; especially the embedding part.
It's also an open collaborative cross-vendor specification with at least four different independent implementations.
MSIL/CIL is similar in some ways, but it's still largely only supported by Microsoft and doesn't sandbox binaries the same way. It's an inspiration to We assembly, but not a feasible alternative to it. Similar to Google's PNaCl bytecode.
Some more detail here:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... "secure-by-default foundations for native development that are portable and scalable."
Ideally, libraries should only use a very small subset of the POSIX / C-runtime APIs (ideally none which need to call into the underlying operating system), and provide ways for the library user to override this functionality, or not depend on those at all (simple example: allow to provide input data via memory instead of letting the library call into the C runtime I/O functions). Same for threading: instead of spawning threads inside the library, provide an API which takes "chunks of work", and let the library user care about doing this across multiple threads.
There are so many parties interested in wasm, there are a ton of inflight proposals and extensions to get it beyond the mvp stage.
[0]: https://github.com/WebAssembly/threads [1]: https://github.com/WebAssembly/multi-memory
Development of the spec(s) happen in the open on the various github projects (https://github.com/WebAssembly/). Meeting notes, agendas, proposals, etc... are all kept as markdown in the git repositories.