[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] WebGL-next
This is a bit of idle speculation, but some things stood out to me from the Khronos OpenGL-next roadmap:
- Intermediary bytecode shader format
- Multi-threaded render command submission
- complete API redesign
- statelessness and direct access?
I think some of these will be challenges for the web.
Intermediary bytecode shader format
The main problem here is probably that most simple solutions aren't going to work with it (so source fallback needs to exist). Also, most web developers don't use a precompilation step for their sources. The second problem I see here would be a complete lack of tooling to compile shaders on machines that do not have GPUs (as in webservers). I think Khronos needs to do a huge step forward there and produce a compiler that does not rely on a GPU, is available on all platforms, can easily be installed (a minimum of dependencies) and if at all possible, is open source.
Multi-threaded render command submission
Here the web has a problem. We don't have threads. There's WebWorkers, which is great, but they're not threads. Is it worth considering something like WebThreads so that WebGL-next users could make use of this feature?
Complete API redesign
WebGL does its best to dress up the C-origin API of OpenGL and make it nice to use in JS. But even the best falls somewhat flat because it does need to adhere to the specification and it is still a C API.
I think there's a chance that a new standard could offer for a polyglot environment to provide greater leeway in the concrete interpretation of the API language, so as to make it more idiomatic for any given target.