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

Re: [Public WebGL] Re: WEBGL_get_buffer_sub_data_async

On Sun, Feb 5, 2017 at 11:23 PM, Jukka Jylänki <jujjyl@gmail.com> wrote:
From the "web as a compilation target" side of the world, there's a couple of requests to WebGL and extensions like this:
   - don't require yielding back from the GL render loop to use the feature (native apps like to spin their own render loops, which would be cool to get going in Web Workers one day, but needing to yield to event loop to receive a message from WebGL would hinder this)
I've mentioned this is a trouble for code that compiles to JS. It's pretty awkward to do in emscripten (global callback hooks and whatnot)
   - have 1:1 mapping counterpart to native so code porting is easy
Afaik The 1:1 mapping would be:
  1. bind unpack/read buffer
  2. readBuffer with a buffer binding into the unpack/read buffer
  3. fence/sync
  4. <do something else until signaled>
  5. mapBuffer
  6. memcpy data over
(does native side have the same problem?
if so, what did native do to solve this problem?
if not, why does only the web have such a problem?)
 Because WebGL does not have mapBuffer. The law of unintended consequences when cutting out core features of an API.
I wonder about the original rationale and the underlying problem, which motivated crafting this extension?
There's two large threads on the ML with no clear conclusion on mapBuffer.
Would incorporating a mirror of an existing GLES3 extension to WebGL 2 solve the same problem?