[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] async shader compiliation

It won't help with how long the cold start will take, but it should avoid the freezing Florian mentions (assuming that's what "seizes up" means).

On Mon, Feb 27, 2017 at 10:39 AM, Maksims Mihejevs <max@playcanvas.com> wrote:
Corentin, this will not make cold compilation faster at all. Which is a major problem right now. Caching - is not a solution to slow shader compilation, as caching only benefits consequetive visitors. But in casual nature of web, first visit - is most important.

On 27 Feb 2017 3:04 p.m., "Corentin Wallez" <cwallez@google.com> wrote:
I really think the following could work in Chrome on platforms that have program binaries available (i.e. not OSX). It works today and has been possible for at least a year.

One thing that might work in Chrome with the current state of things would be to go through a list of shaders in a Worker and for each of them:
    • Compile it
    • glFinish (and destroy the shader)
    • send to the main event loop that this shader was warmed up
Then in the main event loop, recompile the shader expecting it to be already warm and instant to compile. However on platforms where the browser cannot use program binaries, things would actually be slower.

On Mon, Feb 27, 2017 at 9:57 AM, Maksims Mihejevs <max@playcanvas.com> wrote:
We have huge commercial project on the way, where we had to avoid any shader recompilation at any cost, which dramatically limits of what can be done with rich content.

On 27 Feb 2017 2:43 p.m., "Florian Bösch" <pyalot@gmail.com> wrote:
Just today I had a call with the architecture client. They've decided to kick the WebGL content (their core offering) off their landing page because it seizes up the machine for 10-15 seconds on a cold-start.

A solution to this issue is desperately needed, not yesterday, not last week, not even last year, it's needed years ago.