[Public WebGL] Re: WEBGL_get_buffer_sub_data_async
Mon Jan 2 12:49:55 PST 2017
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
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