[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Zhenyao Mo [email protected]
Wed Mar 4 10:07:48 PST 2015

There is some text in the section 3.7 of WebGL 2 spec.

  // MapBufferRange, in particular its read-only and write-only modes,
  // can not be exposed safely to JavaScript. GetBufferSubData
  // replaces it for the purpose of fetching data back from the GPU.

Basically we can't just return the pointer from glMapBufferRange to
the javascript in read-only or write-only modes, because there is no
mechanism to enforce read-only or write-only.

Therefore, we have to save the pointer, copy out the buffer range to a
client mem, and return that to user.  When in UnmapBuffer, for write,
we have to copy back the data to the saved pointer.

It does not give you anything more than bufferSubData / getBufferSubData.

On Wed, Mar 4, 2015 at 9:54 AM, Florian Bösch <[email protected]> wrote:
> There hasn't been a discussion on cutting that feature publicly. Though it
> was probably known to the keen observer of the specification. Relevant
> section here: https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14
> Why have these functions been excluded?
> mapBufferRange in particular is tied to a very useful construct which is the
> MAP_UNSYNCHRONIZED_BIT. This allows an upload operation not to block on the
> mapBufferRange call (although the subsequent unmapBuffer before use would
> block, but you can perform other operations in the meantime or use
> double-buffering to avoid intra-frame blocking). A future version of WebGL
> might introduce GL_MAP_PERSISTENT_BIT as well, in which case buffers can be
> used without having to unmap them before use. Overall mapping buffers offers
> a variety of useful semantics to deal with data.
> It'd be useful as preparation for programmers to get acquainted with mapping
> buffer ranges in WebGL now, before it's got to be introduced later on
> because it'll offer irresistible advantages to the specification editors.
> Without knowing the reasons to cut this feature out, I'm going to assume
> it's todo with pointers. I'd like to point out that both mapBuffer and
> mapBufferRange return a pointer in native version, but both also expect a
> size for this buffer to be specified. In WebGL, these calls could return an
> array buffer instead of a pointer.

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list