11–15 of 15 posts
Earlier quoted context omitted.
For what, Firefox is for all practical purposes irrelevant in a Chrome dominated Web, Google can steer WebAssembly into whatever direction fits Chrome.
That's the situation today, but in 2013 when asm.js was invented Firefox was still relevant.
Earlier quoted context omitted.
That's the situation today, but in 2013 when asm.js was invented Firefox was still relevant.
Yes, and the question in retrospective is was it worth it?
Earlier quoted context omitted.
Yes, and the question in retrospective is was it worth it?
IMHO: totally. Asm.js developed into WASM, which is better in any aspect than PNaCl (e.g. just one disadvantage is that PNaCl was an ossified subset of LLVM bitcode, this would resulted in the same quagmire that the DX team found themselves in when they based the DXC shader compiler and HLSL bytecode (DXIL) on a snapshot of the LLVM toolchain and bitcode - in the end the only realistic way out for D3D was to switch t…
Also they would not have such problem, had they used their own MSIL like bytecode instead, like the Phoenix compiler toolchain from MSR that was supposed to eventually replace VC++, in a LLVM like tooling, but ended up being cancelled.
Makes sense to move the window system glue parts on a different 'track'. IME the window system glue is the actually ugly and maintenance heavy part when writing a cross-platform 3D API wrapper. The various core 3D APIs (D3D, Metal, Vulkan, even GL) all map to the same hardware so it's quite trivial to get them to do the same thing. But for the window system glue it gets ugly. Different platforms and window systems do…
Makes sense to move the window system glue parts on a different 'track'. IME the window system glue is the actually ugly and maintenance heavy part when writing a cross-platform 3D API wrapper. The various core 3D APIs (D3D, Metal, Vulkan, even GL) all map to the same hardware so it's quite trivial to get them to do the same thing. But for the window system glue it gets ugly. Different platforms and window systems do…
I thought SDL3 covers everything on that front though? Don't think we need to reinvent the wheel too much for window management.
It just offloads all the pain and hassle to the SDL maintainers. Also SDL is a pretty big beast (partly because it needs to accumulate a lot of hacks and workaround for buggy drivers and window systems). It would be nice when all those accumulated hacks wouldn't be needed in the first place.
For the idea of portable gfx applications in WASI it's also not really an option to base the window system glue standard on SDL (I guess though that SDL could be the base for one specific implementation of the WASI window system glue interface).