Re: Data transfers from/to client

More importantly than GC pressure, probably, is that shimming a C API on
top of a Promise also inherently adds latency:

let resolved = false;
prom.then(() => { resolved = true; });

raf(() => {
  if (resolved) { ... }
}

So I think we'll need something non-promise-based for WASM anyway.

On Wed, Jan 31, 2018 at 11:59 AM Kirill Dmitrenko <dmikis@yandex-team.ru>
wrote:

> When promise-based interface was proposed to the WebGL community, there're
> some concerns about generating garbage (thread:
> https://www.khronos.org/webgl/public-mailing-list/public_webgl/1701/msg00001.php).
> However, maybe those concerns need some qualitative analysis.
>
> 25.01.2018, 22:01, "Corentin Wallez" <cwallez@google.com>:
> > On Wed, Jan 24, 2018 at 9:41 PM, Dzmitry Malyshau <dmalyshau@mozilla.com>
> wrote:
> >> === Shape of the API for data transfers ===
> >>
> >> One of the benefits of having poll-like interface (with fences or
> something similar) is that it maps cleanly to C and thus maps perfectly to
> WASM.
> >> If we choose to have promises instead, how would they be accessible
> from WASM? I don't see anything immediately related in the Host Bindings
> Proposal.
> >
> > I assume you meant the WASM Host Bindings Proposal. I'm not sure about
> direct bindings to promises but implementing a poll-like interface on top
> of a promise interface would be easy to do with a shim. That said I agree
> that it isn't clear how to make it work with minimal overhead in WASM.
> Something important for Chrome is that the range of data that will be
> accessed be explicit, because otherwise we would have to send all of the
> buffer's content through the GPU command buffer. It's easy to see how a
> promise interface could have explicit bounds, but it is less clear how to
> do it with a poll API.
>
> --
> Kirill Dmitrenko
> Yandex Maps Team
>
>