Thank you Florian on coming back on that.
It is important to solve this problem earlier, as solution won't apply immediately an not to all platforms.
But scale of applications grow. While engines and tools improve, larger content is getting developed, and it is already hitting that bottleneck.
So solutions on this topic - are important to enable larger content for the web, not just small mini-games/demos.
#1: Nonblocking compile signaling (@khronos-wg)
Could we introduce a new getProgramParameter variable like gl.COMPILE_FINISHED or similar to produce nonblocking compile signaling? (there was some discussion of this in another thread). As there's no native support AFAIK, how do we avoid stalling the GPU process when checking the gl.COMPILE_STATUS and therefore prevent other shaders from continued compilation?
I think, that would be great to have such check, and it feels like would be the easiest think to implement in short time.
This would allow engines and tools to utilise this on platforms that provide such functionality. It will allow us to have non-blocking loading, as well as non-blocking shader compilation in runtime, with simply async results of compilation. Of course this shall be a user decision to choose behaviour, and tools can provide so.
Although this would not reduce timing of compilation, only avoid blocking, asking developers to hide waiting somehow.
Sync options fell like more robust and would reduce time spent dealing with shaders.
Texture compression - is not mandatory, but powerful feature to be used. It would be amazing if there would be single path for compiled shaders, but due to nature of WebGL platform, that is not the case.
So potentially platform based extension could be engaged.
What important to remember, as with native tools, people don't write engines anymore to make 3D apps. They pick the tool that helps them to get to the target in efficient way. Back in 200s it wasn't a case. But today, same happening to WebGL platform - there is a urge for tools, and they are being developed, providing people with headache-free experience, allowing them to develop their apps, rather than struggle with the platform.
It does not feel that binary shaders is a complex feature. All background workings of WebGL already has functionality to deal with it I'm sure. It is only about exposing such functionality using extensions notation based on platforms.
That would provide block-free shaders, eliminating large JS stalls especially on mobile. On desktop those stalls renders related tabs as frozen, with pretty bad experience, that is comparable to if downloading images on websites would block JS thread :)