[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

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:
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.