On Wed, May 2, 2012 at 7:35 PM, Gregg Tavares (勤) <gman@google.com> wrote:

Compile errors are returned with gl.getShaderParameter(shader, gl.COMPILE_STATUS), Link errors are returned with gl.getProgramParameter(program, gl.LINK_STATUS)

Neither of those are actually an error.

Also, you can compile X shaders and link Y programs all without checking the status of any of them. Which effectively means you can async compile multiple things at once. If you wanted to check them you'd need to able to check them individually, not with something like getLastError. Which one would be get getting the error for?

This is the part I didn't go into, but each getErrorAsync call would return the error as of that point. So,

function() {
    var shader1 = ctx.createShader();
    ctx.shaderSource(shader1, source1);
    ctx.compileShader(shader1);
    ctx.getErrorAsync(func1);

    var shader2 = ctx.createShader();
    ctx.shaderSource(shader2, source2);
    ctx.compileShader(shader2);
    ctx.getErrorAsync(func2);

}

func1 would always be called before func2; both func1 and func2 receive the value that getError would have returned if called at their respective places.

This could be done for any function that returns a value, including getProgramParameter and getShaderParameter. (That does result in a larger surface area, but I suppose this isn't unusual for the platform; actually, most web APIs have both sync and async interfaces for *all* blocking functions.)

AFAIK both of these suggestions will currently only help Chrome. AFAIK all other browsers are calling GL on the same thread as _javascript_ and I know of no GL drivers that compile or link on another thread. I don't know what Firefox or Safari's plans are with regards to WebGL but I suspect if this truly is a priority issue it will either require major re-architecting so that those browsers actually issue GL calls on other threads or it will require an API like asyncCompileShader(s, callback) and asyncLinkProgram(p, callback) that is easier to implement given their current implementations.

(I'm fine with features that only help a single browser to start; that just helps encourage other browsers to improve their implementations.)

But, back to the original point. I'm still not sure this is a priority.

I didn't call it a high priority; that doesn't mean it's not worth thinking about.

--
Glenn Maynard

Re: [Public WebGL] Asynchronous calls