Re: [whatwg] Canvas image to blob/dataurl within Worker

On Wed, Apr 8, 2015 at 8:46 AM, Ashley Gullen <ashley@scirra.com> wrote:
> (sorry for double email) Just one question about how requestAnimationFrame
> is expected to work. Could we get rAF added to workers? Would it be able to
> simply fire whenever it does on the main thread, as if it postMessage'd to
> the worker every time it was called but without the extra postMessage
> latency? To do that I guess workers need to be associated with a window. For
> normal workers this seems fine but if OffscreenCanvas is expected to work in
> shared or service workers this is a little tricker to define. Perhaps
> requestAnimationFrame could be a method on OffscreenCanvas and it fires
> based on the window the HTMLCanvasElement it came from is currently in? Then
> you have a convenient way to synchronise rendering with the window it will
> ultimately be displayed in, without having to know in advance which window
> that is.

A usable requestAnimationFrame will be needed in workers in order to
reliably do animation. I'm hoping that that can be a somewhat
orthogonal proposal to this one. There are two ways to use an
OffscreenCanvas and only one of them causes rendering results to be
pushed implicitly to an existing canvas on the main thread. (The other
way involves directly instantiating an OffscreenCanvas and using
postMessage to do some work on the main thread to display its
results.) requestAnimationFrame is typically triggered on the main
thread as early as possible after the previous frame's vsync interval,
and I'd expect that other workers' requestAnimationFrame callbacks
should be triggered in the same way. Dedicated workers are always
associated with a particular page which is displayed in a window, so
the connection to an on-screen window should always be there.

-Ken


> Ashley
>
>
>
> On 8 April 2015 at 16:36, Ashley Gullen <ashley@scirra.com> wrote:
>>
>> This looks like it will cover running a HTML5 game engine from a worker
>> very nicely and with little performance overhead. Good stuff!
>>
>> Ashley
>>
>>
>> On 8 April 2015 at 00:41, Kenneth Russell <kbr@google.com> wrote:
>>>
>>> On Wed, Mar 25, 2015 at 6:41 PM, Kenneth Russell <kbr@google.com> wrote:
>>> > On Wed, Mar 25, 2015 at 1:22 PM, Robert O'Callahan
>>> > <robert@ocallahan.org> wrote:
>>> >> On Wed, Mar 25, 2015 at 11:41 PM, Anne van Kesteren <annevk@annevk.nl>
>>> >> wrote:
>>> >>>
>>> >>> On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan
>>> >>> <robert@ocallahan.org> wrote:
>>> >>> > My understanding is that the current consensus proposal for canvas
>>> >>> > in
>>> >>> > Workers is not what's in the spec, but this:
>>> >>> > https://wiki.whatwg.org/wiki/WorkerCanvas
>>> >>> > See "Canvas in Workers" threads from October 2013 for the
>>> >>> > discussion.
>>> >>> > svn
>>> >>> > is failing me but the CanvasProxy proposal in the spec definitely
>>> >>> > predates
>>> >>> > those threads.
>>> >>> >
>>> >>> > Ian, unless I'm wrong, it would be helpful to remove the
>>> >>> > CanvasProxy
>>> >>> > stuff
>>> >>> > from the spec to avoid confusion.
>>> >>> >
>>> >>> > That proposal contains WorkerCanvas.toBlob, which needs to be
>>> >>> > updated to
>>> >>> > use promises.
>>> >>>
>>> >>> There's also https://wiki.whatwg.org/wiki/WorkerCanvas2 it seems. It
>>> >>> would be interesting to know what the latest on this is.
>>> >>
>>> >>
>>> >> Right now that appears to be just a copy of WorkerCanvas with some
>>> >> boilerplate text added. I assume someone's working on it and will
>>> >> mention it
>>> >> on this list if/when they're ready to discuss it :-).
>>> >
>>> > Yes, apologies for letting it sit there in an incomplete state.
>>> > Recently feedback from more browser implementers was gathered about
>>> > the WorkerCanvas proposal. I will assemble it into WorkerCanvas2 and
>>> > follow up on this thread in a day or two.
>>>
>>> I apologize for taking so long to update this proposal, but it's now
>>> in a reasonable state:
>>> https://wiki.whatwg.org/wiki/OffscreenCanvas
>>>
>>> (Renamed per feedback from Anne -- thanks.)
>>>
>>> Please offer your feedback. Multiple browser implementers agreed on
>>> this form of the API at a recent face-to-face meeting of the WebGL
>>> working group, and the proposal should be able to address multiple use
>>> cases. I'm very interested in prototyping it to see if it can offer
>>> better parallelism.
>>>
>>> -Ken
>>>
>>>
>>>
>>> > -Ken
>>> >
>>> >
>>> >> Rob
>>> >> --
>>> >> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso
>>> >> oaonogoroyo
>>> >> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
>>> >> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
>>> >> owohooo
>>> >> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o
>>> >> o‘oRoaocoao,o’o
>>> >> oioso
>>> >> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo
>>> >> oaonoyooonoeo
>>> >> owohooo
>>> >> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono
>>> >> odoaonogoeoro
>>> >> ooofo
>>> >> otohoeo ofoioroeo ooofo ohoeololo.
>>
>>
>

Received on Wednesday, 8 April 2015 21:52:48 UTC