Re: Grouping in canvas 2d

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 Thu, Jun 13, 2013 at 11:57 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> Last year, I requested if grouping could be added to canvas.
> 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
>
> Rik
>

Received on Friday, 14 June 2013 14:06:48 UTC