HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
100% Positive
Analyzed from 229 words in the discussion.
Trending Topics
#window#system#glue#between#asm#different#ugly#core#apis#same

Discussion (2 Comments)Read Original on HackerNews
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 don't agree on how 3D rendered surfaces should be presented and how frame-pacing is supposed to work, there's a fundamental conflict between event-driven UI apps and frame-driven 'game-y' apps, the window system glue generally seems to get less attention than the core 3D APIs (maybe because it sits exactly between areas of responsibility), there are sometimes subtle behaviour changes between operating system updates (especially on macOS), and let's not even mention Wayland.
The result is that the code which sits between the window system and 3D rendering becomes an accumulation of experimentation, hacks and workarounds, has a very high churn and in the end those 10% of the code base suck up 90% of the work :/
asm.js, like JSON, is a strict subset of the JavaScript grammar that turned out to be very useful in a certain way. Obviously, a text encoding like asm.js wasn't an efficient way to distribute a bytecode, but it proved enough to make wasm the obvious next step.