Re: [w3ctag/design-reviews] OffscreenCanvas new commit() and DedicatedWorker.requestAnimationFrame (#288)

The last I understood was that `.commit()` and `while(true){}` custom main loops are orthogonal concepts. A Worker that is using OffscreenCanvas and `.commit()` to present frames, may be rendering asynchronously event-based in the Worker, or synchronously via `while(true) {} ` custom main loop. The wording in https://github.com/junov/OffscreenCanvasAnimation/blob/master/OffscreenCanvasAnimation.md#the-commit-processing-model suggests that would still be the case?

Browsers should not block `.commit()` to wait until page resumes from background, since that would indeed deadlock Workers and possibly cause event queues to build up, and a barrage of flooded computation when the tab finally resumes. If browsers want to throttle background tabs, they should do that at a global Worker/tab level, after all nothing prevents pages from wasting CPU via a `for(;;) {}` in a Worker today, already without OffscreenCanvas.

The issue with multithreaded applications is that only one Worker in such an application might be doing OffscreenCanvas WebGL rendering, and many other Workers in an app may be doing some other continuously running computation, that can produce and wait for events from the OffscreenCanvas WebGL rendering Worker. If just the OffscreenCanvas Worker paused in `.commit()` as a response to the tab going to background, but other Workers did not, they might keep piling up events to the OffscreenCanvas Worker queue, or they might also pause waiting for something from the OffscreenCanvas Worker. That is why throttling should be considered a) globally or b) cooperatively instead, and not on `.commit()`. If a browser globally throttles the whole tab, then the event queue build-up should be more moderate, since essentially the whole app would suspend, and not just parts of it.

If we think that a computation consists of two separate logical parts: `game/app logic simulation`+`animation rendering`, and would want to reduce the processing of an application to only doing the simulation portion when on the background since the animation bit is redundant, then we should provide APIs that make it possible for application developers to easily opt in to. Giving `requestAnimationFrame()` to Workers makes that bit easier. Emscripten provides uniform API for either main thread or pthread to register to get `visibilitychange` events into the calling thread, which allows applications to cooperatively stop rendering, whether they are in main thread or pthread using OffscreenCanvas, or direct WebGL.

If we wanted something more automatic on the cooperative front, it could be a property `bool suspendMeIfMyTabGoesToBackground` and/or `bool graduallyStartThrottlingMeIfMyTabGoesToBackground` or similar on `WorkerGlobalScope`, which developers would be able to set for Workers they know do not need to do anything if the page is on the background. That would allow developers to eagerly opt in to power saving.

For slightly easier rendering throttling management, it might be nice for `.commit()` to give back an enum return value `0: visible`, `1: hidden` (while at it, `2: contextlost`?) that caller would be able to investigate right there in order to do cooperative throttling in a non-event-based manner, without having to set up `visibilitychange` listeners. And/or perhaps we should make Page Visibility API with is `document.visibilityState` readily available in Web Workers?

But apart from that, I don't think browsers have any other option than to globally throttle all Workers/the whole tab, independent of what they are doing. It is the same problem as how should browser react to `for(;;){}` background Workers already today, the rest is about providing developers with APIs how to easily manage cooperative throttling to ensure that the computation they are generating will be the most reasonable/optimized one for the particular situation at hand?


-- 
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/288#issuecomment-412366464