Re: Data transfers from/to client

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

Received on Wednesday, 31 January 2018 22:07:30 UTC