How similar&#x2F;different is the OffscreenCanvas proposed spec from the CanvasProxy proposed spec?  I thought there were going to be synchronization nightmares to CanvasProxy and that is why browser vendors avoided implementing it.<p>OffscreenCanvas appears to be a special canvas object that you can transfer to a web worker, draw to it there off of the DOM thread, and then &quot;commit&quot; the updates to the associated DOM Canvas.<p>Is the DOM canvas neutered after calling transferControlToOffscreen?  Meaning, can you get a context and draw to the canvas concurrent with the Web Worker, or is the DOM Canvas inaccessible after control is transferred?<p>If it is the latter, then is this OffscreenCanvas just a WebGL-exclusive version of CanvasProxy?  What are the characteristics of WebGL versus 2D-canvas API that make it conducive to Web Workerage?  Not that I&#x27;m complaining, I just don&#x27;t understand what&#x27;s the difference.<p>I&#x27;m curious about how bad the synchronization issues are with OffscreenCanvas in this first implementation.<p>In any case, this may have incredible implications for mobile web game development if the experiment pans out, not to mention desktop games!  Super exciting, I&#x27;ve been dreaming to be unshackled from the DOM thread for years.  Thanks AGAIN, Mozilla!!