Hacker News new | ask | show | jobs
by niutech 879 days ago
Sadly, still no Framebuffer API for WASI GUI apps (https://github.com/WebAssembly/WASI/issues/174).
3 comments

Framebuffers aren’t really a useful abstraction anymore. They can be implemented on top of webgpu anyway.
WebGPU is only in web browsers and WASM runs everywhere. There should be a standard cross-platform API for WASM GUI apps. Framebuffer is the lowest common denominator and <canvas> may be its implementation in web browsers. See also: https://medium.com/wasmer/wasmer-io-devices-announcement-6f2...
> WebGPU is only in web browsers and WASM runs everywhere.

"Web" indicates where it started / was standardized, not where it runs. WebAssembly runs everywhere, WebGPU does too.

There's something related WASI GUI apps that I've been working on for the last few months. Hope to provide details soon.
Excited to see this! There's a need demonstrated need for WASI apps that can draw to a screen/canvas outside of a browser, and hope to see this as another community-driven contribution to WASI.
I have always suspected that sort of thing is somehow blocked by Google because it would make mean web assembly runtimes don't need web browsers.

Although now that there is actually a significant update to WASI, perhaps it's possible that they are just actually that slow? Or maybe both are true.

Probably I am just a "conspiracy nut". I mean I definitely am, but in this case it might just be paranoia.

WASI Co-chair here. Nothing in WASI is "somehow blocked by Google", or indeed blocked by anyone at all. Graphics support in WASI hasn't been developed simply because nobody has put energy into developing graphics support in WASI.

At the end of 2023 we counted around 40 contributors who have been working on WASI specifications and implementations: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contributors so far.

By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .

Thanks for your explanation! Could you please have a look at this proposal of I/O Devices? https://medium.com/wasmer/wasmer-io-devices-announcement-6f2... Is it possible to include a similar FB API in the next versions of WASI?
I hope safari implements these things so I could reasonably run a wasm build of firefox on ios