On Thu, 13 Jun 2013, Rik Cabanier wrote:
>
> The API would look like this:
> 
> void beginLayer();
> void beginLayer(unsigned long x, unsigned long y,
>                 unsigned long w, unsigned long h);
> void endLayer();
> 
> When you call beginLayer, you inherit everything from the graphics state 
> except shadows, opacity and the current compositing mode. Those will 
> reset to their initial value. At endLayer time, the graphics state will 
> be restored and you will draw the content of the group.
> 
> so for instance, if you want multiply blend with opacity of .5
> 
> ctx.globalAlpha = .5;
> ctx.globalCompositeOperation = "multiply";
> ctx.beginLayer();
> ... // drawing
> ctx.endLayer();
> 
> This would cause everything between begin/endLayer to be drawn normally. 
> This result is then blended and composited at endLayer time.
> 
> Last year, people argued that you could achieve the same effect by using 
> a temporary canvas so this API is not really needed. I would like to see 
> if people are more open to this API now.
>
> Reasons to have it:
> - it is easily achievable with existing graphics libraries.
> - it is a very common idiom. You can cut down on the amount of JS 
>   needed.
> - if you want to avoid antialiasing issue, you need to carefully set the 
>   CTM on the temporary canvas and remove the CTM from the current canvas
> - creating a temporary canvas has a higher overhead than simply starting 
>   a layer.
> - creating lots of temporary canvas objects creates memory overhead
> - is polyfillable for older canvas implementations

On Fri, 14 Jun 2013, Brian Salomon wrote:
>
> As an implementor, we would prefer the layer approach. This would have 
> lower overhead in Chromium/Skia. We can make better decisions about 
> caching and deferred rendering. It also seems like a really handy API 
> for devs, especially the ability to inherit the graphics state. Would 
> the spec have anything to say about beginLayer()/endLayer() balancing, 
> especially with respect to RAF?

On Fri, 14 Jun 2013, Rik Cabanier 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.

On Tue, 18 Jun 2013, Justin Novosad wrote:
>
> 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.

On Tue, 18 Jun 2013, Rik Cabanier wrote:
>
> 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.

On Tue, 18 Jun 2013, Justin Novosad wrote:
>
> 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.

On Tue, 18 Jun 2013, Rik Cabanier wrote:
> 
> 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.

On Fri, 14 Jun 2013, Ashley Gullen wrote:
>
> IMO this looks like something that belongs to a framework rather than 
> the web platform. I don't see why you'd ever need "lots of temporary 
> canvas objects", it should only ever require one, which probably has a 
> low enough overhead to not need to worry about too much.

On Fri, 14 Jun 2013, Rik Cabanier wrote:
>
> If you nest layers, there would always be a need for more than 1 but 
> that is not usually a problem. Keeping an extra canvas around 
> just-in-case also seems inefficient since it will need the same 
> dimensions as your whole canvas.
>
> Reusing canvas objects will also make it harder for a browser to 
> optimize/pipeline the drawing.
> 
> This is such a common idiom. Why would we force developers to write 
> complex and error prone code if a simple API change can do the same?

On Mon, 17 Jun 2013, Jürg Lehni wrote:
>
> I am very much interested in this feature. Of course you can use 
> separate canvases to achieve the same, which is what we currently do in 
> Paper.js, but it appears to be rather slow to do so. I think performance 
> could improve a lot which this alternative API proposal.