On Fri, Sep 29, 2017 at 3:36 PM, Florian Bösch <email@example.com> wrote:On Sat, Sep 30, 2017 at 12:25 AM, Kenneth Russell <firstname.lastname@example.org> 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.The memory copy from shared memory between the renderer and GPU processes into the client's ArrayBufferView happens just before the Promise is going to be resolved. We have tested this thoroughly and talked with the implementers of Promises in Chrome. It is guaranteed to work.