[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Floh [email protected]
Wed Mar 4 11:37:23 PST 2015

I've been dabbling with multiple GL contexts on different threads
recently in desktop GL code, and multiple people who I see as quite
the GL experts and who've been through this before gave me the good
advice that 'it's not worth it', and that the whole topic is 'a world
of pain' mainly because the whole area not well specified, lousily
documented, drivers behave differently, and if they work, they still
suffer from thread synchronization issues. I guess that WebGL could
still mimic different contexts in worker threads and allow to call
WebGL functions from workers, as long as the calls can be queued
efficiently to the 'main GL context' under the hood. IMHO the most
interesting topic for parallelization, and which could also be
achieved in WebGL and WebGL2 is resource setup, not trying to
parallelize all types of WebGL calls.


On Wed, Mar 4, 2015 at 7:22 PM, Florian Bösch <[email protected]> wrote:
> Hm, I see. Though the blocking behavior might differ from when the browser
> transfers data between JS-thread and GPU-process, than when the GPU-process
> exchanges with the GPU. Also it's not outside the realm of possibilities
> that at some point WebGL contexts might stand in for real contexts, and
> WebGL code runs in a dedicated WebWorker process that owns that context.
> On Wed, Mar 4, 2015 at 7:15 PM, Zhenyao Mo <[email protected]> wrote:
>> On Wed, Mar 4, 2015 at 10:10 AM, Florian Bösch <[email protected]> wrote:
>> > On Wed, Mar 4, 2015 at 7:07 PM, Zhenyao Mo <[email protected]> wrote:
>> >>
>> >> Basically we can't just return the pointer from glMapBufferRange to
>> >> the javascript in read-only or write-only modes, because there is no
>> >> mechanism to enforce read-only or write-only.
>> >
>> > So what you're saying is there isn't a ReadOnlyArrayBuffer and
>> > WriteOnlyArrayBuffer correct? If I'm not mistaken, returning ArrayBuffer
>> > conformant objects, which impose additional restrictions shouldn't be
>> > terribly hard.
>> You also need to consider some browsers (for example, Chrome) runs GPU
>> in a separate process.  Copying data out and copying data back is the
>> only way to implement this.

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

More information about the public_webgl mailing list