On Sat, Sep 30, 2017 at 12:25 AM, Kenneth Russell <email@example.com> wrote: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.That sounds implausible to me. Underneath chrome would use mapbuffer and fences to implement the required functionality (if it doesn't it has no synchronization i.e. couldn't call back a promise, or would be mapbuffer synced), which afaik does not guarantee client memory not to be overwritten by a subsequent comment in the stream once the fence signals for a previous one.
2) It still requires allocation of an object (a WebGLSync) -- no way around that.It's why I suggested a query like semantic because they can be pre-allocated. Usually (because they're integers) you can keep a ring-buffer of integers (something that makes WebAssembly/asm.js/emscripten folks very happy).