[whatwg] Counterproposal for canvas in workers

[Robert O'Callahan]

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.

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?

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*