Re: [whatwg] Counterproposal for canvas in workers

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