- From: Greggman <notifications@github.com>
- Date: Fri, 29 Jun 2018 20:06:27 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/141/401513211@github.com>
I'm not sure where to bring this up but under the current `OffscreenCanvas.commit()` proposal how are pages that are not the front tab handled?
With rAF the browser just doesn't call the callback. With blocking commit though what's the plan?
* if `commit` blocks then the worker is stuck unable to process other events.
* if `commit` is a no-op then the worker is wasting time even though the user is not viewing the page and the canvas itsehas the wrong content
I can imagine the following patterns with `commit`
1. commit in spin loop
// in worker
while(true) {
render();
offscreenCanvas.commit();
}
2. commit in raf loop
// in worker
const socket = new WebSocket("ws://www.example.com/socketserver");
socket.onmessage = handleMessagesFromServer;
function loop() {
render();
requestAnimationFrame(loop);
offscreenCanvas.commit();
}
requestAnimationFrame(loop);
In case 1 above blocking commit if the page is not the front page seems reasonable. In case 2 it does not because the worker was expecting to be able to process events. How will browsers be able to handle the 2 cases?
--
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-401513211
Received on Saturday, 30 June 2018 03:06:52 UTC