- From: Kenneth Russell <kbr@google.com>
- Date: Tue, 22 Oct 2013 10:20:57 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: whatwg <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
On Tue, Oct 22, 2013 at 7:37 AM, Glenn Maynard <glenn@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. > , 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. > On Mon, Oct 21, 2013 at 9:03 PM, Kenneth Russell <kbr@google.com> wrote: >> >> There are some unexpected consequences of the attachToCanvas API >> style. For example, what if two contexts use attachToCanvas to target >> the same canvas? > > > I left out these details in my initial post in order to see what people > thought at a high level before delving into details. 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 . -Ken
Received on Tuesday, 22 October 2013 17:21:22 UTC