[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

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

On Tue, Mar 17, 2015 at 6:35 PM, Zhenyao Mo <[email protected]> wrote:
> With WRITE bit, without INVALIDATE bit, for out-of-process
> implementations, we have to append READ bit internally, and read out
> the whole buffer range, send it to the js, so it can be written to
> partially.  Otherwise, how can you write back in unmap time? unless
> you keep track of which elements in the buffer range have been written
> to and which remain untouched.
You're thinking of one particular way to implement it. The way you're
thinking of, is to synchronize the copy, and then flush the whole copy on
unmap. That's why you're talking of readback for write.

Readback for write makes no sense. An alternative to this necessarily slow
and cumbersome idea, would be to transfer the data to be written, and write
that data to the appropriate underlying mapped range. No readback, no huge
in/out of process performance differences.

The queue of writes to perform doesn't need to be individually transferred
and performed either, an out of process implementation would be free to
delay writes to the underlying till it's queued/collated enough writes into
a block for IPC transfer.

> For out-of-process implementations, using the invalidate bit makes a
> huge per difference.  for Map call, it doesn't have to wait for the
> service side to return the buffer range, it can just allocate a buffer
> and initialize to 0 and allow js to write to it.  Otherwise, it's a
> blocking call until service side responded with the readback buffer
> data.

This argument is borne again out of this flawed idea how to do things which
you imply as a given, but it isn't, see above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150317/db85084d/attachment.html>

More information about the public_webgl mailing list