Re: [whatwg] OffscreenCanvas from a worker and synchronization with DOM/CSS

[Kenneth Russell]

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

[Elliott Sprehn]

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

[Gregg Tavares]

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.

Re: [whatwg] OffscreenCanvas from a worker and synchronization with DOM/CSS

[Gregg Tavares]

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

[Domenic Denicola]

+Justin who gave a talk on this feature at BlinkOn.







From: Anne van Kesteren
Sent: Friday, November 13, 2015 09:54
To: WHATWG
Subject: [whatwg] OffscreenCanvas


Thanks to Olli I discovered
https://wiki.whatwg.org/wiki/OffscreenCanvas is much further along
than I thought. Is anyone planning on creating a PR against
https://github.com/whatwg/html for the more formal specification of
this feature? (And simultaneously ripping out the old worker canvas
text.)


--
https://annevankesteren.nl/

Re: [whatwg] OffscreenCanvas

[Justin Novosad]

Yes. I plan to transform that proposal into a PR soon-ish. But first I will
submit a PR that removes proxy canvas and friends (which no one has
implemented AFAIK).

[whatwg] OffscreenCanvas

[Anne van Kesteren]

Thanks to Olli I discovered
https://wiki.whatwg.org/wiki/OffscreenCanvas is much further along
than I thought. Is anyone planning on creating a PR against
https://github.com/whatwg/html for the more formal specification of
this feature? (And simultaneously ripping out the old worker canvas
text.)


-- 
https://annevankesteren.nl/