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

I don't know who's reading what where but on top of the issues mentioned above with `commit` are a host of others. Sorry to repeat this stuff but I have no idea if there is one official place to discuss this stuff or if I should just keep repeating myself in every place it's bought up.

The biggest issue is that `commit` (AFAIK) effectively creates a new kind of environment in the browser. It's use case is supposedly for native ports using spin loops

     while(true) { 
        render();
        gl.commit();
     }

Once you do that all access to all other APIs stops working in that worker because all other APIs are event based (onmessage, fetch, websockets, rAF, setTimeout, setInterval, etc...)

Is that fact well under by the people reviewing this proposal?

The people pushing for `commit` know that implication and are suggesting that a worker using a `commit` spin loop will be communicated with via shared arraybuffers since other communication becomes impossible.

It seems like there are a bunch of issues with that direction. For example it seems to make throttling hard. You can block the commit indefinitely when the page using it is not the front tab BUT, if you block then any other workers or the main thread will suddenly stop having their shared arraybuffer exchanges respond. While it might be possible to correctly program for that case I have a feeling it will lead to tons of subtle race conditions for most apps trying to use it. It was also suggested in that case that instead of blocking the browser might just throttle (eg. only process commit once a second) but that also seems like a bad idea as it will likely make using the browser extremely unresponsive until the tab using the spin loop is closed.

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