On Wed, May 14, 2014 at 6:30 AM, Jürg Lehni <li...@scratchdisk.com> wrote:

> On Apr 30, 2014, at 00:27 , Ian Hickson <i...@hixie.ch> wrote:
> > On Mon, 7 Apr 2014, Jürg Lehni wrote:
> >>
> >> Well this particular case, yes. But in the same way we allow a group of
> >> items to have an opacity applied to in Paper.js, and expect it to behave
> >> the same ways as in SVG: The group should appear as if its children were
> >> first rendered at 100% alpha and then blitted over with the desired
> >> transparency.
> >>
> >> Layers would offer exactly this flexibility, and having them around
> >> would make a whole lot of sense, because currently the above can only be
> >> achieved by drawing into a separate canvas and blitting the result over.
> >> The performance of this is real low on all browsers, a true bottleneck
> >> in our library currently.
> >
> > It's not clear to me why it would be faster if implemented as layers.
> > Wouldn't the solution here be for browsers to make canvas-on-canvas
> > drawing faster? I mean, fundamentally, they're the same feature.
> I was perhaps wrongly assuming that including layering in the API would
> allow the browser vendors to better optimize this use case.

No, you are correct; having layers will make drawing more efficient as you
can make certain assumptions and you don't have to create/recycle
intermediate canvas's.

> The problem with the current solution is that drawing a canvas into
> another canvas is inexplicably slow across all browsers. The only reason I
> can imagine for this is that the pixels are copied back and forth between
> the GPU and the main memory, and perhaps converted along the way, while
> they could simply stay on the GPU as they are only used there. But reality
> is probably more complicated than that.

I don't know why this would be. Do you have data on this?

> So if the proposed API addition would allow a better optimization then I'd
> be all for it. If not, then I am wondering how I can get the vendor's
> attention to improve this particular case. It really is very slow
> currently, to the point where it doesn't make sense to use it for any sort
> of animation technique.

I think we just need to find some time to start implementing it. The API is
simple and in the case of Core Graphics, it maps directly.

Reply via email to