The efficient use cases that I see is: you map with INVALID* bit, so
you just get a pointer you can write to. This saves you the extra
copying between CPU memory (js array) to vram, comparing with
bufferSubData. Unfortunately that benefit is no longer there for
non-in-process WebGL implementations.
Unless there is a way to map a vram pointer to other processes on all platforms.
On Mon, Mar 16, 2015 at 11:11 AM, Florian Bösch <firstname.lastname@example.org> wrote:
> Even on native platforms mapBuffer[Range] isn't more efficient than
> bufferSubData. Instead of blocking on the buffer[Sub]Data call, it just
> blocks on the memcpy. If you set the asynchronous flag, it won't block, but
> it'll still block on unmap and/or flush, which isn't more efficient than
> buffer[Sub]Data. The only case where mapBuffer[Range] is faster is if you're
> doing asynchronous ping-poned doubled buffered updates and issue no other
> blocking command to the driver. Desktop GL has more options, but ES 3 does
> On Mon, Mar 16, 2015 at 7:07 PM, Zhenyao Mo <email@example.com> wrote:
>> Oh I failed to type the keyword "efficiently". My bad.
>> On Mon, Mar 16, 2015 at 10:55 AM, Florian Bösch <firstname.lastname@example.org> wrote:
>> > On Mon, Mar 16, 2015 at 6:03 PM, Zhenyao Mo <email@example.com> wrote:
>> >> If it comes to a vote, I will vote "no" for introducing something to
>> >> the core APIs that intrinsically cannot be implemented on
>> >> non-in-process WebGL implementations.
>> > What exactly isn't implementable about it?