- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 13 Apr 2012 20:06:02 -0700
Not having an implementation of BackgroundImage makes blending in SVG very difficult. I'm unsure why you think that specifying a magenta color will change the color model to subtractive. As far as I know, the renderer is always computing in RGB. Rik On Fri, Apr 13, 2012 at 6:35 PM, David Dailey <ddailey at zoominternet.net>wrote: > Perhaps if some of the browsers start to implement blend modes for > disposable graphics they'll finally start to do it properly for SVG as > well. > > I've had a devil of a time figuring out if Opera or IE/ASV properly handles > some of the effects at http://cs.sru.edu/~ddailey/svg/V9.svg since none of > the other browsers are brave enough to try it. The first two diagrams > should > display, respectively, additive and subtractive color, while some of the > others experiment with more intuitive color models using feImage to find > region intersections and or simple opacity. Humans, without training tend > not to thing R+G=Y (additive) or even that B+Y=G (subtractive), in part > because tetrachromacy in the visual cortex seems to override whatever > trichromacy we have at the retinal level (varies by gender, btw). > > Also methodologies that estimate color differences on the basis of JND's > (such as the CIE work in Rochester in the 1930') may not generalize well to > distances that are further across the perceptual space, methinks. > > Cheers > David > > -----Original Message----- > From: whatwg-bounces at lists.whatwg.org > [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Rik Cabanier > Sent: Friday, April 13, 2012 1:49 PM > To: David Geary > Cc: Jeremy Apthorp; Ashley Gullen; whatwg at whatwg.org > Subject: Re: [whatwg] Adding blending to the canvas API > > 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-canva > >> s-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 20:06:02 UTC