[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Tue Mar 17 12:33:17 PDT 2015

This pushback against mapped buffers isn't good. It's not good because
mapped buffers aren't going away.

In ES 3.0 the following functionality is offered for mapBufferRange:

   - array buffers
   - copy read buffers
   - copy write buffers
   - element array buffers
   - pixel pack buffers
   - pixel unpack buffers
   - transform feedback buffers
   - uniform buffers
   - flushMappedBufferRange

ES 3.1 adds the following new functionality to mapBufferRange:

   - atomic counter buffer
   - dispatch indirect buffer
   - draw indirect buffer
   - shader storage buffer

GL 4.0 adds the following new functionality to mapBufferRange:

   - query buffer
   - bufferStorage (and its associated flags which also add new)
      - via glMemoryBarrier

And that was just mapBufferRange, mapBuffer itself is also expanded. In
fact most options for dealing with and structuring memory transfer behavior
are not contained in the buffer[Sub]Data calls, they've all migrated to the
variety of buffer handling/mapping routines.

Nobody knows what Vulkan will bring, but I'm fairly certain mapping buffers
is going to be part of it.

It's of no practical use to ignore this feature. It's a problem that needs
to be solved (and solved efficiently and as closely resembling the
underlying APIs behavior) as possible. If you don't solve it now, you'll
have this exact same debate again for WebGL 2.1, WebGL 3.0, WebVulkan 1.0,
WebVulkan 2.0 and so forth. Except that by the time that it got trough to
this standards body that mapped buffers aren't going anywhere, it'll come
in a zillion colorful fashions of options and it will be very, very hard to
implement as a first throw.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150317/b82f07b9/attachment.html>

More information about the public_webgl mailing list