- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Fri, 18 Oct 2013 10:28:27 +1300
- To: Justin Novosad <junov@google.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
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. 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 * *
Received on Thursday, 17 October 2013 21:28:51 UTC