W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Counterproposal for canvas in workers

From: Justin Novosad <junov@google.com>
Date: Thu, 17 Oct 2013 17:56:19 -0400
Message-ID: <CABpaAqRFwW27Uqko-Fjoa4tO90RoiVLBy0p7Ka8Bad2PeRcdXg@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
On Thu, Oct 17, 2013 at 5:50 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Thu, Oct 17, 2013 at 2:28 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Fri, Oct 18, 2013 at 6:57 AM, Justin Novosad <junov@google.com> wrote:
>>
>>> Here is similar concept, but with an API more like WokerCanvas:
>>> The CanvasRenderingContext2D associated with a WorkerCanvas would only
>>> record draw commands, without executing them. The context would be
>>> write-only. When you call commit on the WorkerCanvas, the block of
>>> recorded
>>> draw commands would be posted back to the main thread or directly to the
>>> compositor.
>>
>>
>> Which? They are observably different.
>>
>>
>>> What I like about this approach is that it is always just
>>> pushing data downstream, thus eliminating buffer synchronization issues
>>> as
>>> well as the need for double buffering canvas backing stores.
>>>
>>
>> The write-only restriction is a problem. Also, it's really important that
>> the worker be able to create temporary canvases for its own use (pdf.js for
>> example needs this), and this doesn't really support that.
>>
>
> Creating temporary canvases is still possible. I'm unsure how it would be
> different from a worker.
> An advantage would be that you can draw to the temporary canvases in
> parallel to using them. Only PIXEL access is disallowed, you can still call
> drawImage using a canvas that has outstanding tasks.
>

Right. The write-only restriction would only apply to canvas contexts that
commit (push their tasks) directly down to the compositor. You could still
create a canvas that is local to the worker, rasterize it in the worker and
do readbacks in the worker, create ImageBitmaps from it, etc.

>
>
>>
>> I think we have already converged on a WorkerCanvas design that everyone
>> (on this thread so far) is happy with, using ImageBitmaps to synchronize
>> with the main thread as needed. Is there some problem with that proposal
>> that warrants introducing the complexity of Rik's 'task' system or the
>> limitations of your proposal?
>>
>
> It seemed like that proposal was harder. Synchronization with the main
> drawing thread seemed and the continuous committing seemed difficult too.
> In addition, Ken wanted multiple workers access the same canvas which I
> didn't see addressed (unless I missed it).
>
> If the other proposal is better, we can drop this one.
>
Received on Thursday, 17 October 2013 21:56:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC