[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] async shader compiliation
Some user stories to help highlight different ways this issue affects users:
1. Simple WebGL app "Load and Show". In this case all content is loaded and shaders usually compiled in advance. In this scenario developer is limited to shader complexity. Additionally developer currently cannot start compiling shaders while browser is downloading assets.
2. Async WebGL app "Load, show, continue loading, show more". In this case some content is loaded and some shaders are compiled. But more content is loaded as user progresses through application, and more shaders need to be compiled. Currently developer is very enforced to be concerned about what shaders will be needed. Leading to dynamic shader componsition becomes very pricey. This enforces to rethinking async approach in web development, which is a power of web, but is restricted due to shader compilation stalls.
3. Procedural app. Shadertoy is a good example. It is possible to create resources procedurally, and is a very attractive idea - no much to download, just generate textures and geometry on GPU, and you can have rich applications with loads of content. But this is not viable. It turns out downloading assets is usually faster than generating them, and generation - is not a slow bit, it is complex shaders compilation what leads to large stalls, making procedural approach very limited as well.
We've encountered vast issues with shader compilation at PlayCanvas and it is a constant blocker for many things, that leads to reduced user experience.
We believe that currently it is most major blocker for WebGL, to allow rich content being delivered in a good manner to web users.
Can't express how important solving this is for a whole WebGL platform is.