Re: [whatwg] Grouping in canvas 2d

I


On Wed, Dec 4, 2013 at 11:41 AM, Jürg Lehni <lists@scratchdisk.com> wrote:

> 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?


I would love if this was implemented. Last attempt stalled because Simon
Fraser objected. Simon, do you still object?


> 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 21:36:21 UTC