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. 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. 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. J