First point: we didn't discuss other forms of the API except for MapBuffer and the current proposal. I forgot to look back at this thread before the meeting, and we were running low on time.
Second point: it would be possible to recast the API in the form discussed back in February. Here is a slightly modified version:
var ext = gl.getExtension('WEBGL_get_buffer_sub_data_async');
var buffer = new Float32Array(1234);
var sync = null;
function readBuffer(){
extension.getBufferSubDataAsync(target, 0, buffer);
if(sync !== null){
gl.deleteSync(sync);
}
sync = gl.fenceSync(gl.SYNC_GPU_COMMANDS_COMPLETE);
}
function bufferReady(){
return gl.getSyncParameter(sync, gl.SYNC_STATUS) == gl.SIGNALED
}
readBuffer();
function raf(){
if(bufferReady()){
doSomethingWithData();
readBuffer();
}
requestAnimationFrame(raf);
}
raf();
However this is likely to be less efficient than the current Promise-based API for the following reasons:
1) The browser guarantees that the Promises resolve in order, and that even if all the Promises use the same ArrayBufferView, inside the promise's resolve callback, the data is the correct value with respect to the OpenGL command stream at the time that iteration of getBufferSubDataAsync was called. Multiple frames can be queued up without needing separate destination ArrayBufferViews. The polling-based API requires a new ArrayBufferView for each readback, if the application expects to have multiple frames in flight.
2) It still requires allocation of an object (a WebGLSync) -- no way around that.
It would be good to get feedback from more folks about these issues.
Still, I've filed
http://crbug.com/770381 to think about this more and possibly try it out before we push this extension forward.
-Ken