[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 <zmo@chromium.org> wrote:
On Wed, Mar 4, 2015 at 10:10 AM, Florian Bösch <pyalot@gmail.com> wrote:
> On Wed, Mar 4, 2015 at 7:07 PM, Zhenyao Mo <zmo@chromium.org> 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.