- 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