W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2013

Re: [whatwg] Grouping in canvas 2d

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 14 Jun 2013 11:39:12 -0700
Message-ID: <CAGN7qDCAC0p4+NnYzapAgt+aJM8aO_6KrGmjcdWG+PXS_6ZGGQ@mail.gmail.com>
To: Ashley Gullen <ashley@scirra.com>
Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
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
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 Fri, Jun 14, 2013 at 10:13 AM, Ashley Gullen <ashley@scirra.com> 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.
> Ashley
> On 14 June 2013 04:57, 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 18:39:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:55 UTC