- From: Brian Salomon <bsalomon@chromium.org>
- Date: Fri, 14 Jun 2013 09:04:33 -0400
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg@whatwg.org, public-canvas-api@w3.org
- Message-ID: <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com>
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