[whatwg] Adding blending to the canvas API

[Rik Cabanier]

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 :)
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
>
>
>