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

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. Let's call them, `mainWorker` and `presentationWorker`. `mainWorker` is where  the application's never-ending ui loop runs. On `mainWorker` we have an OffscreenCanvas object that is used for preparing frames, let's call it `backBuffer`. `backBuffer` is created directly using the OffscreenCanvas constructor (i.e. it is not associated with a placeholder canvas element).  On the other hand, `presentationWorker` has an OffscreenCanvas object that is associated with a placeholder canvas. Let's call that one `frontBuffer`. When `mainWorker` wants to commit a frame, it would do something like this:

```
let frame = backBuffer.transferToImageBitmap();
presentationWorkerMessagePort.postMessage({frame: frame}, [frame]);
```

On the presentation worker side, the message handler would receive the frame and simply push it to `frontBuffer`.  For this to be as streamlined as possible, we should expose ImageBitmapRenderingContext in workers, which is a trivial change.  The only reason it is not currently exposed in workers is because there was no use case for it... until now. Alternately, the role of `presentationWorker` could be implemented on the main thread, but it is nice to have it in a worker which allows frames to be continuously pushed to the display without delay even when the main thread is busy.

To implement vsync throttling behavior, `presentationWorker` could run a requestAnimationFrame loop that signals frame barriers to 'mainWorker' via a semaphore implemented using SharedArrayBuffer. On the `mainWorker` side, the throttling would be implemented using a call to Atomics.wait() on the frame barrier semaphore.

I think this is a more reasonable solution than forwarding WebGL calls.  ImageBitmap objects are transferable, so there is very little overhead in serializing them for postMessage. Implementations can wrap GPU textures inside ImageBitmap objects. Also, postMessage is required by the spec to be immediate, so it will work fine to call it from a never-ending task.

@juj WDYT?

-- 
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-344389070