[Public WebGL] WebGL2 element array buffer and copy buffer (5.1 Buffer Object Binding)

Ken Russell ([email protected]) [email protected]
Thu Jul 9 10:49:06 PDT 2020

WebGL implementations that can't rely on robust buffer access behavior
shadow the contents of ELEMENT_ARRAY_BUFFERs on the CPU. The
CopyBufferSubData call updates the shadow copies as well, allowing the
maximum index per type and range within the buffer to be computed without

The restrictions in the WebGL specification are there to avoid the need to
shadow the contents of all buffers.


On Thu, Jul 9, 2020 at 10:02 AM Kevin Rogovin ([email protected])
<[email protected]> wrote:

> Hi,
>  Reading the text, it appears that:
> glGenBuffers(1, &index_buffer);
> glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, index_buffer);
> glBindBuffer(GL_COPY_READ_BUFFER, some_other_buffer);
> glBindBuffer(GL_COPY_WRITE_BUFFER, index_buffer);
> someOffset, someLength);
> is legal because index_buffer gets the type "element array", from the
> first bind and binding it to GL_COPY_WRITE_BUFFER is legal because of
> what the table states.
> However, the rational states the restriction is to make sure index
> values are in range, but the above scenario in order to make sure that
> the indices are in range would require that a browser implementation
> would need to peek the buffers via CPU which would defeat the purpose
> of using glCopyBufferSubData() on any index buffer.
> What is expected to happen with the above?
> Best Regards,
>  -Kevin
> -----------------------------------------------------------
> 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
> -----------------------------------------------------------

I support flexible work schedules, and I’m sending this email now because
it is within the hours I’m working today.  Please do not feel obliged to
reply straight away - I understand that you will reply during the hours you
work, which may not match mine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20200709/8340ae4b/attachment.html>

More information about the public_webgl mailing list