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

Re: [Public WebGL] Re: WEBGL_get_buffer_sub_data_async



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



On Fri, Sep 29, 2017 at 2:58 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Fri, Sep 29, 2017 at 10:57 PM, Kenneth Russell <kbr@google.com> wrote:
We want to get this extension out now because there are people clamoring for it.

I want this extension too, pretty badly. But I want it not to be the first of N revisions as in WEBGL_get_buffer_sub_data_async2,  WEBGL_get_buffer_sub_data_async3,  WEBGL_get_buffer_sub_data_async4,  WEBGL_get_buffer_sub_data_async5 because it does things in a fashion completely unusable for some of the constituencies that want to use it.