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

Re: [whatwg] Counterproposal for canvas in workers

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 17 Oct 2013 14:50:08 -0700
Message-ID: <CAGN7qDCCDY-5R3D1_wv4LC5huh6vbCcNdxunbRKqvY2Ago2S+Q@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Justin Novosad <junov@google.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>
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.


>
> 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:50:33 UTC

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