Re: Data transfers from/to client

That's also absolutely true. I would like to enable both. See the doc
Corentin sent for a proposal hopefully allows both (by making the
mapped-object thenable)

On Wed, Jan 31, 2018 at 2:07 PM Kirill Dmitrenko <dmikis@yandex-team.ru>
wrote:

> Yep, there's that. I've raised that point at one of the previous meetings.
> However, after thinking about it for some time, I found an upside to
> promises regarded that situation. If an application doesn't render or do
> background tasks continuously, but only when an update is really needed
> (i.e, as a result of new data from net or user interaction), promises may
> same CPU time is JS:
>
> let raf = 0;
> let rafJobQueue = [];
>
> promise.then((data) => {
>     rafJobQueue.push(data);
>     if (!raf) {
>         raf = requestAnimationFrame(render);
>     }
> });
>
> function render() {
>     for (const data of rafJobQueue) { /* do stuff */ }
>
>     /* render */
>
>     raf = nextFrameNeeded ? requestAnumationFrame(render) : 0;
> }
>
> Same argument goes for requestIdleCallbacks: promises may allow not to
> constantly schedule callbacks for checking if there's something to do.
>
> 31.01.2018, 23:12, "Kai Ninomiya" <kainino@google.com>:
> > 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
>
>
> --
> Kirill Dmitrenko
> Yandex Maps Team
>