W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] <canvas> feedback

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 14 May 2014 21:32:46 -0700
Message-ID: <CAGN7qDB6a-b9WRvbbP3mwa2=EvHp_ASgm=OY1O96pnb1FohmZA@mail.gmail.com>
To: Jürg Lehni <lists@scratchdisk.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Wed, May 14, 2014 at 6:30 AM, Jürg Lehni <lists@scratchdisk.com> wrote:

> On Apr 30, 2014, at 00:27 , Ian Hickson <ian@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.
Received on Thursday, 15 May 2014 04:33:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC