Re: [whatwg] OffscreenCanvas from a worker and synchronization with DOM/CSS
That's right. From discussions with Mozilla I don't think that code path's enabled in their implementation yet, but it will be (as well as in Chrome's future implementation of the same spec). On Sat, Jan 23, 2016 at 12:40 PM, Gregg Tavares wrote: > Never mind me. For whatever reason my mind blanked out. > > You can transfer to the main thread and then apply to a canvas. >
Re: [whatwg] OffscreenCanvas from a worker and synchronization with DOM/CSS
Never mind me. For whatever reason my mind blanked out. You can transfer to the main thread and then apply to a canvas.
Re: [whatwg] OffscreenCanvas from a worker and synchronization with DOM/CSS
I presume you're supposed to just postMessage back to the main thread when you commit(). The spec should probably have a "commit" event though. On Jan 23, 2016 1:49 PM, "Gregg Tavares" wrote: > I just noticed Firefox shipped an OffscreenCanvas implementation. Looking > at the spec it seems there is no way to synchronize updates from a worker > with dom/css manipulations. > > Was this already discussed? There are web apps that synchronize HTML dom > elements with canvas updates. I'm sure they'd all love to gain the benefits > of being able to render to their canvas from a worker. But, if they can't > synchronize the canvas update with their DOM element position updates there > will be unacceptable skewing/judder/issues > > Maybe it was already decided but I couldn't find the discussion. It seems > like a pretty bold thing to do for HTML because it basically encourages > using as little HTML/DOM/CSS as possible rather than encouraging just doing > some fancy rendering in a worker and the rest in HTML. > > A few example of apps that would love to get the benefit of offscreen > rendering in a worker but could not without some way to synchronize > > Apple Maps > https://youtu.be/bBs3sqH27Kk > > Baidu Maps > https://youtu.be/dT-k-xI5UYw > > Yahoo Japan Maps > https://youtu.be/DYVEILUCRZQ > > Worse, those things that could have been HTML but are no longer HTML can't > be used in standard ways. For example because Yahoo Japan's Maps use HTML a > translation extension, Rikaikun, is able to provide translations. The > current OffscreenCanvas spec effectively discourages using HTML elements in > these cases making features like these impossible. > > Rakaikun on Yahoo Japan Maps > https://youtu.be/sQ68V8ggwB0 > > Another example which would seem really relevant to WebVR is to allow > various parts of a scene to be presented as a fully functional web page > like this example > > > > http://learningthreejs.com/blog/2013/04/30/closing-the-gap-between-html-and-webgl/ > > but that won't work if you can't synchronize dom and offscreencanvas. >
[whatwg] OffscreenCanvas from a worker and synchronization with DOM/CSS
I just noticed Firefox shipped an OffscreenCanvas implementation. Looking at the spec it seems there is no way to synchronize updates from a worker with dom/css manipulations. Was this already discussed? There are web apps that synchronize HTML dom elements with canvas updates. I'm sure they'd all love to gain the benefits of being able to render to their canvas from a worker. But, if they can't synchronize the canvas update with their DOM element position updates there will be unacceptable skewing/judder/issues Maybe it was already decided but I couldn't find the discussion. It seems like a pretty bold thing to do for HTML because it basically encourages using as little HTML/DOM/CSS as possible rather than encouraging just doing some fancy rendering in a worker and the rest in HTML. A few example of apps that would love to get the benefit of offscreen rendering in a worker but could not without some way to synchronize Apple Maps https://youtu.be/bBs3sqH27Kk Baidu Maps https://youtu.be/dT-k-xI5UYw Yahoo Japan Maps https://youtu.be/DYVEILUCRZQ Worse, those things that could have been HTML but are no longer HTML can't be used in standard ways. For example because Yahoo Japan's Maps use HTML a translation extension, Rikaikun, is able to provide translations. The current OffscreenCanvas spec effectively discourages using HTML elements in these cases making features like these impossible. Rakaikun on Yahoo Japan Maps https://youtu.be/sQ68V8ggwB0 Another example which would seem really relevant to WebVR is to allow various parts of a scene to be presented as a fully functional web page like this example http://learningthreejs.com/blog/2013/04/30/closing-the-gap-between-html-and-webgl/ but that won't work if you can't synchronize dom and offscreencanvas.