Re: [w3ctag/design-reviews] Review OffscreenCanvas, including ImageBitmapRenderingContext (#141)

> This does NOT provide the nice while(await) pattern that has been discussed by the Offscreen Canvas team, but it seems like it would be trivial to write a promise-emitting wrapper around the rAF callbacks if that's needed?

I'm still not sure if the `while(await)` thing is what people want even. It does not seem to solve real problems, except in example cases to make a couple of lines (that weren't a problem to begin with(?)) look pretty - in more complex cases it runs into the same problems of having to sync->async transform a codebase in a rippling difficult-to-refactor fashion (https://github.com/junov/OffscreenCanvasAnimation/issues/1). This is not to say anything negative about it, making code snippets look simpler and cleaner is nice and has value, but just that I'm looking at `while(await)` through the lens of problems I'm exposed to solving.

> @juj do you have performance data regarding the perf impact of relaying WebGL Commands?

I am able to compile and run simple test GL apps at the moment, but still running into some codegen bugs for full blown WebGL 2 content. This is currently in progress, and I'm hoping to do comparative benchmarks as soon as I get Wasm-based multithreading landed. We do implement both relayed (proxied in Emscripten's parlance) WebGL mode and a non-relayed mode using OffscreenCanvas, so we will have both abilities to be able to compare apples to apples.

> I would like to propose a solution for the problem exposed by juj@ that would work in a world where all we have for driving animations is a rAF API. It uses two workers.

>From my test code that uses main browser thread to schedule rAF pings over to Web Worker, and a Web Worker that synchronously renders a small test cube, I find that frame rates are fluctuating quite bad in this kind of model, and my current estimate is that this is due to timing variances from processing these events. Gut estimate here says that making per-frame rendering or .commit() timings tie in to the event queues of Workers will be already a lost cause from latency and variance perspective, because of slowness coming from threads going to sleep and waking up to process those events. A Worker doing synchronous .commit() in OffscreenCanvas gives much more predictable frame rates in this kind of model However these tests were run with asm.js based implementation of multithreading, and I'm looking to do this kind of testing proper after I am finished with migrating to Wasm multithreading.

Relaying/proxying commands via SAB seems to have good performance, as long as one can do that asynchronously and by "filling a full pipe" of work to be done in a sequence so that processing doesn't starve or stall.

Preliminarily, I think that syncing to vsync in a Worker would be most ideally done using a mechanism that does not require intervention from other Workers or from the main thread.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/141#issuecomment-344609565