- From: Jürg Lehni <lists@scratchdisk.com>
- Date: Wed, 4 Dec 2013 20:41:12 +0100
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Justin Novosad <junov@google.com>, WHAT Working Group <whatwg@whatwg.org>, public-canvas-api@w3.org, Brian Salomon <bsalomon@chromium.org>
This discussion seems to have stalled. Implementing this would help us greatly to optimize aspects of Paper.js, as double buffering into separate canvases is very slow and costly. Is this still on the map? There appears to be a library that emulates this functionality, using the same approach (and having a similar impact on performance) as we do : https://github.com/evanmoran/composite Perhaps this can serve as a base for further discussion? Jürg On Jun 18, 2013, at 18:14 , Rik Cabanier <cabanier@gmail.com> wrote: > On Tue, Jun 18, 2013 at 7:25 AM, Justin Novosad <junov@google.com> wrote: > >> >> >> >> On Fri, Jun 14, 2013 at 2:34 PM, Rik Cabanier <cabanier@gmail.com> wrote: >>> >>> >>> I think so. If you leave a layer 'open', what would you display. >>> It wouldn't just be for requestAnimationFrame, you would also need to >>> define what happens if you read pixels with getImageData inside a >>> beginLayer. >>> >>> >>> >> I would like to suggest that all layers left 'open' should be >> automatically closed at the end of a script execution task. Otherwise, it >> would be too easy to leak layers and get OOM crashes. This would also >> guarantee that the canvas contents are in a ready to display state. >> > > That sounds reasonable. Does this happen with save/restore as well? > If you want to draw incrementally, you wouldn't want this to happen either. > > >> >> For the getImageData question I think the options that would make most >> sense are either: >> a) Read from the root layer (up to date except for contents of currently >> open layers), >> b) Read from the current (top most) layer, or >> c) Fail >> These options will never require the compositing of open (potentially >> unfinished) layers, which I think is important for implementations to be >> efficient. >> I am not sure which of the above makes more sense though. >> > > This is probably a case where we need to check with the implementors. > Safari is the only browser that bolts the canvas implementation straight > onto the OS calls so we should probably spec out what they do since other > browser can probably emulate it.
Received on Wednesday, 4 December 2013 22:02:20 UTC