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

[Florian Bösch <pyalot@gmail.com>]

On Tue, Mar 17, 2015 at 6:35 PM, Zhenyao Mo <zmo@chromium.org> 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.