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

Re: [Public WebGL] Asynchronous calls

Shameless plug here, but
a flow control library like async or Frame.js would help sort out these callbacks.

As brilliant as async is, its often much more difficult to get JS to be synchronous when you need it to be.

anyway, my .02, bz

On May 3, 2012, at 12:11 PM, Gregg Tavares (勤) wrote:

On Wed, May 2, 2012 at 6:09 PM, Glenn Maynard <glenn@zewt.org> wrote:
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);

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

I think you must have a different understanding of GL than I do.

   glCompileShader on every driver I know of is a synchronous call.

So if you want this to be async following your model you need that function to be called on another thread from another context. The model above gives the browser no clue that it needs to be called from another thread in another context until it's too late.
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