W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2012

[whatwg] Adding blending to the canvas API

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 13 Apr 2012 10:48:51 -0700
Message-ID: <CAGN7qDCQ3cqtOL65TvOQ67qG1vYi+AgXRmvVKAEYe_FGKoZzPA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:07 GMT