> > On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan <rob...@ocallahan.org > >wrote: > >> >> > This code actually does something potentially useful which can't easily >> be >> > done with attachToCanvas: generating a series of images as fast as >> possible >> > which will be processed on another thread in some way other than just >> > rendering them on the screen. (E.g., be encoded into an animated image >> or >> > video file.) >> > (Err, wait. A few issues come to mind. 1: You can already say createImageBitmap(canvas) to create an ImageBitmap, which handles the "store a snapshot of a frame" use cases. 2: If the reason to have a "transfer" version for these use cases is just an optimization, then it's not obvious that it's a useful optimization. The use cases you mention suggest a GPU readback anyway. 3: If you're doing the encoding yourself in script, you want ImageData anyway, not ImageBitmap. I don't object as such to adding such a method if it's useful, and I don't think I have the energy right now to debate these in much depth, but this feels like taking a proposal and searching for uses for it.)
On Tue, Oct 22, 2013 at 12:20 PM, Kenneth Russell <k...@google.com> wrote: > On Tue, Oct 22, 2013 at 7:37 AM, Glenn Maynard <gl...@zewt.org> wrote: > > I just noticed that Canvas already has a Canvas.setContext() method > > That's there in support of CanvasProxy, which is a flawed API and > which this entire discussion is aiming to rectify. > I don't see flaws with the setContext() API, which appears to have already solved the problem of being able to make one context render to multiple canvases. Any relation to CanvasProxy isn't relevant to this. > > , which > > seems to do exactly what I'm proposing, even down to clearing the > backbuffer > > on attach. The only difference is that it lives on Canvas instead of the > > context--the only reason I put it there in my proposal was because this > only > > seemed useful for WebGL. Given that, I think this proposal can be > > simplified down to just: "put setContext on WorkerCanvas too". > > Also, adding a present() method to Canvas. > That's mixing up proposals, actually. Adding present() is for the "explicitpresent" proposal, which aims at solving the "synchronizing rendering in a worker to DOM changes in the main thread" use cases. Reusing setContext() replaces my attachToCanvas() proposal, which is for the "one context rendering to multiple canvases)" use cases. They're orthogonal, not mutually exclusive, and solve different problems. (We're mixing up proposals because we're trying to solve too many problems simultaneously, which is one reason I've tried to split this stuff into smaller chunks.) > At a high level I prefer the form of the WorkerCanvas API, including > transferToImageBitmap and the ability to transfer an ImageBitmap into > an HTMLImageElement for viewing, and removing the CanvasProxy concept > and associated APIs. I'd like to focus my own efforts in writing a > full draft for WorkerCanvas under > http://wiki.whatwg.org/wiki/Category:Proposals . > Again, this is a supplement to WorkerCanvas, not a replacement for it. (It may be compatible with CanvasProxy too, but I haven't looked at it closely to see.) We're circling around: you keep saying we should use transferToImageBitmap, I keep pointing out the problems with it that my proposal solves, and you reply by saying "we should use transferToImageBitmap", without addressing those problems. I don't think we have any more information to bring to the discussion right now, so I think we're at a good point to wait for Hixie to get around to these threads rather than going over the same stuff again (and giving him more reading material :). Here's a summary of my proposal: - The WorkerCanvas adjustments to CanvasProxy (minus the transferToImageBitmap stuff), to better address the "rendering to a Canvas from a worker" and "creating off-screen Canvases in a worker"-related use cases. - Include setContext() on WorkerCanvas, to support rendering from one context to multiple canvases when in a worker. - Add "explicitpresent" and present() to Canvas, to support synchronizing rendering in a worker to DOM changes in the main thread without forcing that synchronization on everybody. The second and third are independent and can be implemented separately, after WorkerCanvas itself has time to settle. -- Glenn Maynard
