Re: [whatwg] Canvas in workers

2013-10-20 Thread Robert O'Callahan
Glenn, taking a step back for a bit, is there anything in https://wiki.mozilla.org/User:Roc/WorkerCanvasProposal that you would actually object to? IOW, is there anything there that you would think is completely superfluous to the platform if all your proposals were to be adopted as well? Rob --

Re: [whatwg] Canvas in workers

2013-10-20 Thread Robert O'Callahan
On Sun, Oct 20, 2013 at 5:29 PM, Glenn Maynard wrote: > That's not the problem attachToCanvas tries to solve. It tries to solve > rendering to multiple canvases, without requiring synchronization with the > UI thread. I have a proposal for handling synchronization with DOM > updates, but I'll p

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

2013-10-20 Thread Robert O'Callahan
On Sun, Oct 20, 2013 at 5:33 PM, Glenn Maynard wrote: > Example: > > > > var canvas = document.querySelector("#canvas"); > var worker = createWorker(); > worker.postMessage({ > cmd: "init", > canvas: canvas.getWorkerCanvas(), > }); > > worker.onmessage = function(e) > { > // The wor

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

2013-10-20 Thread Robert O'Callahan
On Mon, Oct 21, 2013 at 4:46 AM, Glenn Maynard wrote: > On Sun, Oct 20, 2013 at 9:26 PM, Kyle Huey wrote: > > > On Sun, Oct 20, 2013 at 11:33 PM, Glenn Maynard >wrote: > > > >> It must not be possible for the UI thread to detect whether present() > did > >> anything--if there's no frame in the

Re: [whatwg] Counterproposal for canvas in workers

2013-10-20 Thread Rik Cabanier
On Sun, Oct 20, 2013 at 7:09 PM, Kyle Huey wrote: > I think most of these have been said already, but my issues with (my > understand of?) this proposal are: > > 1. It requires defining a new script execution environment different from > both the main thread and workers. That seems like a lot of

Re: [whatwg] Counterproposal for canvas in workers

2013-10-20 Thread Rik Cabanier
On Sun, Oct 20, 2013 at 12:28 AM, Robert O'Callahan wrote: > On Fri, Oct 18, 2013 at 6:50 AM, Rik Cabanier wrote: > >> Extra methods on the canvas API: >> >> Promise setTaskScript(DOMString script); // can error be in promise? >> Promise executeTask(DOMString id, dictionary json, boolean synchron

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

2013-10-20 Thread Glenn Maynard
(Whoops. Why did Gmail send that as my work email? It shouldn't have made it through to the list, since it's not subscribed...) On Sun, Oct 20, 2013 at 9:26 PM, Kyle Huey wrote: > On Sun, Oct 20, 2013 at 11:33 PM, Glenn Maynard wrote: > >> It must not be possible for the UI thread to detect w

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

2013-10-20 Thread Kyle Huey
On Sun, Oct 20, 2013 at 11:33 PM, Glenn Maynard wrote: > It must not be possible for the UI thread to detect whether present() did > anything--if there's no frame in the ready buffer, nothing changes and the > UI thread can't detect this. Similarly, it must not be possible for the > rendering th

Re: [whatwg] Counterproposal for canvas in workers

2013-10-20 Thread Kyle Huey
I think most of these have been said already, but my issues with (my understand of?) this proposal are: 1. It requires defining a new script execution environment different from both the main thread and workers. That seems like a lot of unnecessary work. And this execution environment is either

Re: [whatwg] [2D Canvas] Proposal: Losing and restoring rendering contexts

2013-10-20 Thread Rik Cabanier
Hi Justin, I spoke with some game developers and they are really pleased with this proposal. Adobe introduced a similar concept in Stage3D. Some of the pain points/mistakes of that implementation (such as the throwing of exceptions during a context loss) are addressed in this approach. On Fri, O

[whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

2013-10-20 Thread Glenn Maynard
(This is a spin-off thread from "Canvas in workers". Some of this is written in terms of the WorkerCanvas proposal, but it works fine with the current CanvasProxy API. I'm skipping some steps here and going straight to a proposal, since my main goal at the moment is to detangle this from the othe

Re: [whatwg] Canvas in workers

2013-10-20 Thread Glenn Maynard
On Sat, Oct 19, 2013 at 10:11 AM, Robert O'Callahan wrote: > It's not clear to me how attachToCanvas works. An application like Google > Maps wants to draw to multiple canvases from a worker and then render the > updated canvas contents all at once, in synchrony with changes to the DOM > made by t

Re: [whatwg] Counterproposal for canvas in workers

2013-10-20 Thread Glenn Maynard
On Sun, Oct 20, 2013 at 2:22 AM, Robert O'Callahan wrote: > > On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard wrote: >> >> Also, with the "transferToImageBuffer" approach, if you want to render >> >> from a worker into multiple canvases in the UI thread, you have to post >> >> those ImageBuffers

Re: [whatwg] Counterproposal for canvas in workers

2013-10-20 Thread Robert O'Callahan
On Fri, Oct 18, 2013 at 6:50 AM, Rik Cabanier wrote: > Extra methods on the canvas API: > > Promise setTaskScript(DOMString script); // can error be in promise? > Promise executeTask(DOMString id, dictionary json, boolean synchronized = > true); // Transferable elements allowed in dictionary > >

Re: [whatwg] Counterproposal for canvas in workers

2013-10-20 Thread Robert O'Callahan
On Fri, Oct 18, 2013 at 4:17 PM, Glenn Maynard wrote: > On Thu, Oct 17, 2013 at 10:25 PM, Robert O'Callahan >wrote: > > On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard wrote: > >> Also, with the "transferToImageBuffer" approach, if you want to render > >> from a worker into multiple canvases in