[whatwg] Counterproposal for canvas in workers
robert at ocallahan.org
Thu Oct 17 14:28:27 PDT 2013
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
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?
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 *
More information about the whatwg