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

Re: [Public WebGL] Re: WEBGL_get_buffer_sub_data_async

+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...