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.
