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

So I tried it and at least in Chrome `commit` seems to be broken

[This example](http://jsfiddle.net/greggman/gmpkvu30/) does this

```
const appInfo = {
  clientWidth: 300,
  clientHeight: 150,
};
function render() {
    resize if canvas size does not match client size
    render scene
    requestAnimationFrame(render);
    gl.commit();
}
onmessage = update appInfo clientWidth and clientHeight
```

The worker as no way of knowing that size the drawingbuffer needs to be so the main thread sends that info whenever it changes. But, once the worker starts no messages ever arrive from the main thread even though the main thread is sending them. Given that gl.commit is synchronous and many other things are going on it seemed best to call `rAF` before `gl.commit` so that the next animation frame comes as soon as possible. 

In [this sample](http://jsfiddle.net/greggman/gpnqt7db/) I swapped the order to `rAF` after `gl.commit` but it also never receives messages from the main thread

Also note using `gl.commit` no events are delivered period. [Here's an example that tries to load a texture using `fetch`](http://jsfiddle.net/greggman/sp2x6qoz/). **The fetch callback is never received**

This seems far from completely specced. Having `commit` basically make the entire rest of the platform fail to work seems wrong but the spec does not make it clear what is supposed to happen. My guess is chrome promotes rAF events to the top of the event queue so regardless of what other events are pending the rAF event gets run first and then `gl.commit` blocks processing.

That could be a bug in Chrome but AFAICT it's not wrong based on the spec. I think the spec should be clear how these messages get processed when there's a raf+commit loop as well as just `commit` loop.






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