W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Grouping in canvas 2d

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 14 Jun 2013 11:34:28 -0700
Message-ID: <CAGN7qDBHT_fitzzsrnGe6exCWr1Fc4mXSnY=_KW7fNjkoB6-KA@mail.gmail.com>
To: Brian Salomon <bsalomon@chromium.org>
Cc: whatwg@whatwg.org, public-canvas-api@w3.org
On Fri, Jun 14, 2013 at 6:04 AM, Brian Salomon <bsalomon@chromium.org>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?
>

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 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 18:34:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC