[whatwg] Counterproposal for canvas in workers

[Rik Cabanier]

On Thu, Oct 17, 2013 at 2:28 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Oct 18, 2013 at 6:57 AM, Justin Novosad <junov at 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.