- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 13 Apr 2012 10:48:51 -0700
On Fri, Apr 13, 2012 at 10:36 AM, David Geary <david.mark.geary at gmail.com>wrote: > On Fri, Apr 13, 2012 at 11:16 AM, Rik Cabanier <cabanier at gmail.com> wrote: > >> On Fri, Apr 13, 2012 at 2:17 AM, Ashley Gullen <ashley at scirra.com> wrote: >> >> > This looks very handy for games as well! Things like 'screen' work very >> > nicely for some effects, especially explosions. >> >> Yes, these effects are very commonly used in games, animation and artwork. >> > > And presumably having them implemented by browser vendors will be more > efficient than doing it by hand. > Correct. I've found a case where someone implemented this themselves and it is very slow so it's not useful if you want to create an animation or a game. > > > Surely you'd want to extend the existing list of globalCompositeOperation >> > though? >> > >> >> That seemed the easiest way to go. >> I can see some edge cases that you wouldn't be able to implement easy (ie >> do a src-out with a screen). I think it would still be possible to do but >> it would take an extra step. > > > And presumably the extra step will be less efficient than if the browser > did it. Also, the developer must implement the extra step. It seems to me > that the extra step may also require an additional offscreen bitmap. > Correct. The question is if you want to extend the API if the feature is not that common. > > > Otherwise you'd have to define how globalCompositeOperation and > > > globalBlendOperation interact. >> > > >> > My spec is trying to define how they interact. Basically, blending is >> done >> first and replaces the original source. This new source is then >> composited. >> > > Sorry, I?m confused. If that?s how they interact, then musn?t blending and > compositing be separate things? If you extend the list of > globalCompositeOperation valid values to include blends, then you can do > either a blend or a composite, but not both. > Specifying a blend mode would imply doing a src-over with the result of the blend. Every authoring application (not just Adobe's) that I know of, implements it that way. > > >> >> Thanks for the feedback! >> >> Rik >> >> > >> > On 12 April 2012 00:39, Rik Cabanier <cabanier at gmail.com> wrote: >> > >> >> :-) >> >> They are definitely more familiar to designers but they both have their >> >> place. >> >> >> >> On Wed, Apr 11, 2012 at 4:30 PM, Jeremy Apthorp <jeremya at chromium.org >> >> >wrote: >> >> >> >> > On Wed, Apr 11, 2012 at 4:05 PM, Rik Cabanier <cabanier at gmail.com> >> >> wrote: >> >> > >> >> >> All, >> >> >> >> >> >> I'm working on a spec to add blending and compositing through simple >> >> CSS >> >> >> keywords. It is trying to define a generic model that is not >> specific >> >> to >> >> >> Canvas, HTML or SVG and then lists how the model could be >> implemented. >> >> >> We've gotten some comments that this feature would be useful in >> Canvas >> >> as >> >> >> well so I was wondering if it made sense to add it to the canvas >> API. >> >> >> >> >> >> I can see 2 ways of adding this: >> >> >> 1. extend the list of compositing operators ( >> >> >> >> >> >> >> >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing >> >> >> ) >> >> >> with blending. This is what is currently in the draft spec ( >> >> >> >> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.htmlchapter 7) >> >> >> >> >> >> >> 2. create a new attribute on the context called >> 'globalBlendOperation' >> >> >> that >> >> >> takes the same list of blend operations as css ( >> >> >> >> >> >> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend-mode >> >> >> ) >> >> >> >> >> >> Any thoughts? >> >> >> >> >> > >> >> > This seems much more useful than the existing composite operations :) >> >> > >> >> >> > >> > >> > >
Received on Friday, 13 April 2012 10:48:51 UTC