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

[Public WebGL] Asynchronous calls



Currently, most WebGL calls, like OpenGL, are allowed (though not required) to be asynchronous.  finish() or getLastError() will flush the queue, synchronously waiting for the previous commands to finish.  This is good for rendering, where you normally avoid calling those functions at all, but it means some operations that should be asynchronous--shader compilation, most recently--are effectively synchronous, since you always want to call getLastError to make sure your shaders compiled and your program linked.

A generic solution for this is an asynchronous getLastError.  For example,

var shader = ctx.createShader();
ctx.shaderSource(shader, source);
ctx.compileShader(shader);
ctx.getLastErrorAsync(function(e) {
    // All commands up to this point are flushed, and e is the error value.  Check the result and start compiling the next shader.
});
return;

The callback is called when the result is available.

There are other details (eg. what to do if more WebGL calls are made after getLastErrorAsync but before returning, and if multiple getLastErrorAsync calls are made after that), which I'll put off talking about; for now I'll just put the basic idea out there for people to think about.  This could allow making much better use of the asynchronous nature of WebGL/OpenGL, especially at load time (where most getLastError calls are made).

It could also allow checking for errors during rendering, which is currently prohibitively expensive, because calling this function wouldn't cause a stall.

It wouldn't help with other functions that return values (eg. getParameter), but this is the one that usually matters most.

This is probably fairly complex to implement.  It may require running the underlying OpenGL/GLES context in its own thread (maybe they already do this; it seems like a good idea on its own).  I'm not sure about D3D. 

--
Glenn Maynard