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

Re: [Public WebGL] Re: WEBGL_get_buffer_sub_data_async

From the "web as a compilation target" side of the world, there's a couple of requests to WebGL and extensions like this:
   - have the entry points generate no garbage (like mentioned above already)
   - 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)
   - have 1:1 mapping counterpart to native so code porting is easy (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?)

I wonder about the original rationale and the underlying problem, which motivated crafting this extension? Would incorporating a mirror of an existing GLES3 extension to WebGL 2 solve the same problem?


2017-02-05 7:28 GMT+02:00 Maksims Mihejevs <max@playcanvas.com>:
+1 to non-promise approach.

On 4 Feb 2017 7:24 p.m., "Florian Bösch" <pyalot@gmail.com> wrote:
So anyway, I'm not against fences per se, can we drop the promise and go for fences for the obvious benefits of not having to create a promise for every single readback?

On Fri, Feb 3, 2017 at 8:28 PM, Florian Bösch <pyalot@gmail.com> wrote:
The problem of any GC'ing is that despite years of promises that GC'ing will get better, it's still in the realm of dropping several frames. This is a cheapening inconvenience for ordinary WebGL apps that just make them look unpolished, but it's a crushing burden on WebVR apps where frame drops are painfully obvious to every user all the time.

Everything the WebGL API does potentially one or multiple times per frame should have guarantees not to incur GC overhead. And by extension, everything you'd usually end up needing to do with those things that you'd do one or multiple times per frame should have guarantees to have no GC overhead (such as sticking things into lists).

It would've been easier if WebGL followed ES'es principle of returning integers instead of objects. Integers are nicely hashable, and they have no GC overhead. Also lists of integers are treated preferentially by the JIT...