On Thu, Jan 12, 2017 at 3:23 AM, Kenneth Russell <email@example.com> wrote:The reason Promises were chosen for this extension is that they're the current best practice on the web platform for expressing asynchronous computation.Queries are the established best practice for asynchronous computation in realtime and GL code. Queries can also be adapted to emit promises with a few simple lines of JS code for anybody who wishes to do so.The syntax is fluent, and it would have been difficult for me to argue with Chrome's leadership that there was a significant enough performance implication that a raw callback should be passed, contrary to the design of all other current web specs.Callbacks are irrelevant to the discussion if we should rather use queries.Kai and Jaume Sanchez ( https://www.clicktorelease.com/ ) are preparing another test case based on one of Jaume's global illumination examples. Once that's ready we'll post more data. At a high level, using this asynchronous API lets Chrome's deeply pipelined WebGL implementation match the performance of single-threaded and/or single-process WebGL implementations, though the code has to be changed to know about and take advantage of the extension.A note on the examples cited so far, the most common one, object picking, should be done with an occlusion query, not with a getBufferDataAsync.Here is an alternative proposal using query semantics:
- GET_BUFFER_SUB_DATA_ASYNC_WEBGL constant to be used by gl.beginQuery
- getBufferSubDataAsync(target, offset, buffer)Only those two primitives would need to be introduced to make it fully asynchronous, example:In addition to this being compatible with query semantics, this also offers the chance to complete many readbacks with a single query. For instance.