[Public WebGL] Re: WEBGL_get_buffer_sub_data_async
Mon Jan 2 14:27:22 PST 2017
Worth mentioning that promises are extremely bad for GC and real-time
applications, they do not provide a developer enough control to structure
logic so to avoids any allocations.
Promises - are not good for real-time at all, and lead to issues with GC.
Any API in WebGL that is meant to be used in real-time applications should
not be based on API's that are not real-time friendly.
On 2 January 2017 at 20:49, Florian Bösch <[email protected]> wrote:
> Upon thinking about this extension, I don't think it should exist at all.
> Ideally the mapBuffer semantic would be exposed. But even if it isn't, it
> shall not be that an extension is required to express functionality already
> found in the core functionality of the underlying ES specification.
> Furthermore, getBufferSubDataAsync does not adequately express the reality
> of map/flush/unmap, and hides the fact that unmap/flush are still
> synchronizing calls happening. However getBufferSubDataAsync obstructs
> appropriate code dealing with proper insertion of synchronization points.
> In addition, it would lead to allocating promises once or many times per
> frame, and since tracking would be required in some instances, would also
> lead to allocating a closure once or many times a call. An issue that map
> buffer range does not exhibit.
> Due to the lack of discussion of this feature, I believe a great
> disservice is done to WebGL 2 by the introduction of these ideas/APIs and I
> strongly suggest to withdraw this from draft immediately and go back to the
> drawing board.
> On Mon, Jan 2, 2017 at 5:48 PM, Florian Bösch <[email protected]> wrote:
>> This extension https://www.khronos.org/registry/webgl/extensions/
>> WEBGL_get_buffer_sub_data_async/ has been introduced and elevated to
>> draft without any public discussion.
>> In a nutshell it proposes a new WebGL2 function called
>> getBufferSubDataAsync which returns a promise that will be called
>> eventually with the buffer data.
>> I think there are several problems:
>> 1. The extension process states that "*Extensions move through four
>> states during their development: proposed, draft, community approved, and
>> Khronos ratified**"*. This extension never moved through the proposal
>> 2. The extension introduces promises to the WebGL API. This requires
>> a more fundamental discussion.
>> 3. A discussion if this extension is required if WebWorkers can
>> access the same context as the main thread has not happened.
>> This extension should be in proposal status, and the necessary
>> discussions should happen first.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl