CSS Filter Effects for Canvas 2D Context

[Ronald Jett]

Hello,

I think that bringing the new CSS filters (http://html5-demos.appspot.com/static/css/filters/index.html) to canvas might be a good idea. Some of the new filters, specifically blur, would definitely speed up some applications. I saw that there was a previous discussion on this list about bringing SVG filters to canvas, but it was a few years back and it doesn't seem like the discussion yielded much.

It would be great if you could turn the filters on and off while drawing. Something like:

ctx.blur(20); // turns on a 20px blur
ctx.drawRect(0, 0, 50, 50); // this will be blurred
ctx.blur(0); // turns off blur
ctx.drawRect(100, 100, 50, 50); // this will not be blurred

You could even do multiples:

ctx.blur(2);
ctx.sepia(1);
ctx.drawImage(img, 0, 0);
ctx.endFilters(); // turn all filters off

Another benefit of having these effects in canvas is that we could utilize toDataURL to save out an image that a user/application has filtered.

Thoughts?

- Ronald


..............................................

Ronald Jett
Interactive Developer
LEVEL | SJ
Desk: 408.275.7117
Cell: 408.332.1986
http://level-studios.com

[Chris Marrin-2]

On Jan 24, 2012, at 11:56 AM, Ronald Jett wrote:

> Hello,
>
> I think that bringing the new CSS filters (http://html5-demos.appspot.com/static/css/filters/index.html) to canvas might be a good idea. Some of the new filters, specifically blur, would definitely speed up some applications. I saw that there was a previous discussion on this list about bringing SVG filters to canvas, but it was a few years back and it doesn't seem like the discussion yielded much.
>
> It would be great if you could turn the filters on and off while drawing. Something like:
>
> ctx.blur(20); // turns on a 20px blur
> ctx.drawRect(0, 0, 50, 50); // this will be blurred
> ctx.blur(0); // turns off blur
> ctx.drawRect(100, 100, 50, 50); // this will not be blurred
>
> You could even do multiples:
>
> ctx.blur(2);
> ctx.sepia(1);
> ctx.drawImage(img, 0, 0);
> ctx.endFilters(); // turn all filters off
>
> Another benefit of having these effects in canvas is that we could utilize toDataURL to save out an image that a user/application has filtered.
>
> Thoughts?

You can apply CSS Filters to a Canvas element. Maybe it would be better to put the items you want filtered into a separate canvas element and use CSS Filters on that? The big advantage of doing it that way is that the CSS filters can be animated and hardware accelerated. Adding filter functions to canvas would require you to re-render the items for every filter change and you'd have to animate it all yourself.

Generally, I think that often a hybrid approach to Canvas, where you draw into multiple Canvas elements and use CSS transforms, animations (and now filters) for positioning and effects can give you the best of both worlds...

-----
~Chris
cmarrin@...

[David Dailey]

Of course if we go back enough years, there was a recommendation that
foreign object be implemented across browsers so that any HTML content could
be filtered with the power of SVG (including the relatively lightweight
canvas). I think people worried that HTML would become obsolete then.

Cheers
David

-----Original Message-----
From: whatwg-bounces@...
[mailto:whatwg-bounces@...] On Behalf Of Chris Marrin
Sent: Tuesday, January 24, 2012 7:23 PM
To: Ronald Jett
Cc: whatwg@...
Subject: Re: [whatwg] CSS Filter Effects for Canvas 2D Context


On Jan 24, 2012, at 11:56 AM, Ronald Jett wrote:

> Hello,
>
> I think that bringing the new CSS filters
(http://html5-demos.appspot.com/static/css/filters/index.html) to canvas
might be a good idea. Some of the new filters, specifically blur, would
definitely speed up some applications. I saw that there was a previous
discussion on this list about bringing SVG filters to canvas, but it was a
few years back and it doesn't seem like the discussion yielded much.
>
> It would be great if you could turn the filters on and off while drawing.
Something like:

>
> ctx.blur(20); // turns on a 20px blur
> ctx.drawRect(0, 0, 50, 50); // this will be blurred
> ctx.blur(0); // turns off blur
> ctx.drawRect(100, 100, 50, 50); // this will not be blurred
>
> You could even do multiples:
>
> ctx.blur(2);
> ctx.sepia(1);
> ctx.drawImage(img, 0, 0);
> ctx.endFilters(); // turn all filters off
>
> Another benefit of having these effects in canvas is that we could utilize

toDataURL to save out an image that a user/application has filtered.
>
> Thoughts?

You can apply CSS Filters to a Canvas element. Maybe it would be better to
put the items you want filtered into a separate canvas element and use CSS
Filters on that? The big advantage of doing it that way is that the CSS
filters can be animated and hardware accelerated. Adding filter functions to
canvas would require you to re-render the items for every filter change and
you'd have to animate it all yourself.

Generally, I think that often a hybrid approach to Canvas, where you draw
into multiple Canvas elements and use CSS transforms, animations (and now
filters) for positioning and effects can give you the best of both worlds...

-----
~Chris
cmarrin@...

[David Geary-3]

On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin <cmarrin@...> wrote:

>
> On Jan 24, 2012, at 11:56 AM, Ronald Jett wrote:
>
> > I think that bringing the new CSS filters (
> http://html5-demos.appspot.com/static/css/filters/index.html) to canvas
> might be a good idea. Some of the new filters, specifically blur, would
> definitely speed up some applications. I saw that there was a previous
> discussion on this list about bringing SVG filters to canvas, but it was a
> few years back and it doesn't seem like the discussion yielded much.
> >...
> > Thoughts?
>
> You can apply CSS Filters to a Canvas element. Maybe it would be better to
> put the items you want filtered into a separate canvas element and use CSS
> Filters on that? The big advantage of doing it that way is that the CSS
> filters can be animated and hardware accelerated.

That advantage fixes a problem that shouldn't exist: You shouldn't have to
choose one technology over another because one is hardware accelerated.
That's ridiculous.


> Adding filter functions to canvas would require you to re-render the items
> for every filter change and you'd have to animate it all yourself.
>

Sure, but you must create a superfluous canvas for each set of images that
you animate, and invoke an entirely different technology to apply the
filter. You must  make sure that those superfluous canvases have
transparent backgrounds, no borders, and have the correct Z order so they
appear over, and not under, the primary canvas for the application. And I'm
sure there are other gotchas to this hybrid approach that don't immediately
come to mind.

I'd much rather use the filtering underlying API and control the rendering
and animation myself.


> Generally, I think that often a hybrid approach to Canvas, where you draw
> into multiple Canvas elements and use CSS transforms, animations (and now
> filters) for positioning and effects can give you the best of both worlds...
>

I disagree. I would much rather see filter functionality available to both
Canvas and CSS. That functionality is clearly in both Canvas' and CSS'
wheelhouses, and since they are both implemented by the browser vendor, why
not have that low-level functionality available to both Canvas and CSS? It
seems crazy to me to have that low-level code sitting in the browser and
then restrict it to CSS. Why would anyone want to do that?


David
corehtml5canvas.com


>
> -----
> ~Chris
> cmarrin@...
>
>
>
>
>

[Boris Zbarsky]

On 1/25/12 3:41 PM, David Geary wrote:
> On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin<cmarrin@...>  wrote:
>> You can apply CSS Filters to a Canvas element. Maybe it would be better to
>> put the items you want filtered into a separate canvas element and use CSS
>> Filters on that? The big advantage of doing it that way is that the CSS
>> filters can be animated and hardware accelerated.
>
> That advantage fixes a problem that shouldn't exist: You shouldn't have to
> choose one technology over another because one is hardware accelerated.
> That's ridiculous.

Indeed.  Especially since what's accelerated and what's not is likely to
be UA-dependent and not be time-invariant, moving in the direction of
more and more things being accelerated.

-Boris

[Tab Atkins Jr.]

On Wed, Jan 25, 2012 at 6:41 AM, David Geary <david.mark.geary@...> wrote:

> On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin <cmarrin@...> wrote:
>> Adding filter functions to canvas would require you to re-render the items
>> for every filter change and you'd have to animate it all yourself.
>
> Sure, but you must create a superfluous canvas for each set of images that
> you animate, and invoke an entirely different technology to apply the
> filter. You must  make sure that those superfluous canvases have
> transparent backgrounds, no borders, and have the correct Z order so they
> appear over, and not under, the primary canvas for the application. And I'm
> sure there are other gotchas to this hybrid approach that don't immediately
> come to mind.
>
> I'd much rather use the filtering underlying API and control the rendering
> and animation myself.

Yes, it's effectively creating an ad-hoc retained-mode API out of
multiple <canvas> elements solely so it can apply filtering.

(Using multiple backing canvases to sprite things is a reasonable
performance hack, but I don't think it should be required for basic
functionality.)

~TJ

[Ashley Gullen]

I'd like to bring up this subject again especially now that first
implementations are starting to appear.

IMO the big use case here is games - the CSS filters are great for
interesting visual effects.  However there doesn't seem to be a way to use
them in canvas rendering, other than applying the effect to an entire
canvas. Games typically want to apply effects to individual objects
(meaning individual drawImage() calls), and there is no good way to do
this.  Stacking separate canvas elements is out of the question, because it
makes Z ordering with effects impossible.  Consider trying to overlay an
image with no effect on top of an image with an effect.  Also consider the
fact canvas has compositing modes like "lighter" and "destination-out", but
CSS filters do not provide these. This makes it impossible to combine CSS
filters and composite modes. An example is displaying an additive blended
explosion (typical in games) on top of an image with a blur CSS filter,
which seems to be impossible to achieve at all.

One way to define this is to specify that drawImage(), when passed another
canvas as a parameter, must take in to account the canvas' 'filter' CSS
property.  So to draw an image with a blur you'd render using an
intermediate canvas, e.g.

tempcanvascontext.drawImage(myimage, 0, 0);
tempcanvas.style.filter = "blur(10px)";
gamecanvascontext.drawImage(tempcanvas, 0, 0); // draws with blur

Another way would be just to add a 'filter' property to the 2D context,
e.g.:

gamecanvascontext.filter = "blur(10px)";
gamecanvascontext.drawImage(myimage, 0, 0);

This would also be extremely powerful if custom CSS shaders are also
supported, allowing for user-written effects in the canvas 2D context.

Effects should should apply to all drawing operations for consistency,
including lines, paths, rectangles and patterns.

I have no idea if this is easy for implementers (would appreciate comments
on that), but hopefully the CSS filter rendering can be recycled with
drawImage().

Another argument is that you should just use WebGL and write shaders for
advanced effects.  This is an option, but given that a filter effect can be
applied to an entire canvas, it seems a waste not to enable it for
individual draw calls, especially given the 2D context is considerably
easier and quicker to code for.

Ashley Gullen
Scirra.com


On 25 January 2012 16:26, Tab Atkins Jr. <jackalmage@...> wrote:

> On Wed, Jan 25, 2012 at 6:41 AM, David Geary <david.mark.geary@...>
> wrote:
> > On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin <cmarrin@...> wrote:
> >> Adding filter functions to canvas would require you to re-render the
> items
> >> for every filter change and you'd have to animate it all yourself.
> >
> > Sure, but you must create a superfluous canvas for each set of images
> that
> > you animate, and invoke an entirely different technology to apply the
> > filter. You must  make sure that those superfluous canvases have
> > transparent backgrounds, no borders, and have the correct Z order so they
> > appear over, and not under, the primary canvas for the application. And
> I'm
> > sure there are other gotchas to this hybrid approach that don't
> immediately
> > come to mind.
> >
> > I'd much rather use the filtering underlying API and control the
> rendering
> > and animation myself.
>
> Yes, it's effectively creating an ad-hoc retained-mode API out of
> multiple <canvas> elements solely so it can apply filtering.
>
> (Using multiple backing canvases to sprite things is a reasonable
> performance hack, but I don't think it should be required for basic
> functionality.)
>
> ~TJ
>

[Rik Cabanier-2]

On Mon, Jul 16, 2012 at 1:02 PM, Ashley Gullen <ashley@...> wrote:

> I'd like to bring up this subject again especially now that first
> implementations are starting to appear.
>
> IMO the big use case here is games - the CSS filters are great for
> interesting visual effects.  However there doesn't seem to be a way to use
> them in canvas rendering, other than applying the effect to an entire
> canvas. Games typically want to apply effects to individual objects
> (meaning individual drawImage() calls), and there is no good way to do
> this.  Stacking separate canvas elements is out of the question, because it
> makes Z ordering with effects impossible.  Consider trying to overlay an
> image with no effect on top of an image with an effect.  Also consider the
> fact canvas has compositing modes like "lighter" and "destination-out", but
> CSS filters do not provide these. This makes it impossible to combine CSS
> filters and composite modes. An example is displaying an additive blended
> explosion (typical in games) on top of an image with a blur CSS filter,
> which seems to be impossible to achieve at all.
>
> One way to define this is to specify that drawImage(), when passed another
> canvas as a parameter, must take in to account the canvas' 'filter' CSS
> property.  So to draw an image with a blur you'd render using an
> intermediate canvas, e.g.
>
> tempcanvascontext.drawImage(myimage, 0, 0);
> tempcanvas.style.filter = "blur(10px)";
> gamecanvascontext.drawImage(tempcanvas, 0, 0); // draws with blur
>
> Another way would be just to add a 'filter' property to the 2D context,
> e.g.:
>
> gamecanvascontext.filter = "blur(10px)";
> gamecanvascontext.drawImage(myimage, 0, 0);
>
> This would also be extremely powerful if custom CSS shaders are also
> supported, allowing for user-written effects in the canvas 2D context.
>
> Effects should should apply to all drawing operations for consistency,
> including lines, paths, rectangles and patterns.
>
> I have no idea if this is easy for implementers (would appreciate comments
> on that), but hopefully the CSS filter rendering can be recycled with
> drawImage().
>
> Another argument is that you should just use WebGL and write shaders for
> advanced effects.  This is an option, but given that a filter effect can be
> applied to an entire canvas, it seems a waste not to enable it for
> individual draw calls, especially given the 2D context is considerably
> easier and quicker to code for.
>
>

I agree that it would be great to have filter effects in Canvas. It should
be fairly efficient if you have a GPU backend since the effects can all be
done with shaders so it should take up too much memory.
This workflow could even support our CSS shaders proposal. Also since CORS
is no longer an issue with Canvas, we could remove all the limitations we
had to build in to ensure security.

I would be worried about performance in CPU implementations though...

>
> On 25 January 2012 16:26, Tab Atkins Jr. <jackalmage@...> wrote:
>
> > On Wed, Jan 25, 2012 at 6:41 AM, David Geary <david.mark.geary@...
> >
> > wrote:
> > > On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin <cmarrin@...>
> wrote:
> > >> Adding filter functions to canvas would require you to re-render the
> > items
> > >> for every filter change and you'd have to animate it all yourself.
> > >
> > > Sure, but you must create a superfluous canvas for each set of images
> > that
> > > you animate, and invoke an entirely different technology to apply the
> > > filter. You must  make sure that those superfluous canvases have
> > > transparent backgrounds, no borders, and have the correct Z order so
> they
> > > appear over, and not under, the primary canvas for the application. And
> > I'm
> > > sure there are other gotchas to this hybrid approach that don't
> > immediately
> > > come to mind.
> > >
> > > I'd much rather use the filtering underlying API and control the
> > rendering
> > > and animation myself.
> >
> > Yes, it's effectively creating an ad-hoc retained-mode API out of
> > multiple <canvas> elements solely so it can apply filtering.
> >
> > (Using multiple backing canvases to sprite things is a reasonable
> > performance hack, but I don't think it should be required for basic
> > functionality.)
> >
> > ~TJ
> >
>

[Robert O'Callahan-3]

On Tue, Jul 17, 2012 at 4:34 PM, Rik Cabanier <cabanier@...> wrote:

> I agree that it would be great to have filter effects in Canvas. It should
> be fairly efficient if you have a GPU backend since the effects can all be
> done with shaders so it should take up too much memory.
> This workflow could even support our CSS shaders proposal. Also since CORS
> is no longer an issue with Canvas, we could remove all the limitations we
> had to build in to ensure security.
>

CORS is still an issue. You would have to apply the same limitations when
using non-origin-clean source images.

Something like canvas.filter = <CSS-filter-value> would probably be good,
but you'd have to define what the object bounding box for SVG filters is.
This would be useful for Shumway.
https://github.com/mozilla/shumway

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

[Rik Cabanier-2]

On Wed, Jul 25, 2012 at 10:18 PM, Robert O'Callahan <robert@...>wrote:

> On Tue, Jul 17, 2012 at 4:34 PM, Rik Cabanier <cabanier@...> wrote:
>
>> I agree that it would be great to have filter effects in Canvas. It should
>> be fairly efficient if you have a GPU backend since the effects can all be
>> done with shaders so it should take up too much memory.
>> This workflow could even support our CSS shaders proposal. Also since CORS
>> is no longer an issue with Canvas, we could remove all the limitations we
>> had to build in to ensure security.
>>
>
> CORS is still an issue. You would have to apply the same limitations when
> using non-origin-clean source images.
>

Yes,
that is what I meant. CORS is implemented on Canvas for images, so that
logic should be readily accessible to CSS shaders.



>
> Something like canvas.filter = <CSS-filter-value> would probably be good,
> but you'd have to define what the object bounding box for SVG filters is.
> This would be useful for Shumway.
> https://github.com/mozilla/shumway
>
>
If you're looking into emulating flash, you'd probably do it by rendering
to an offscreen canvas (aka movieclip) and then apply the filter to the
whole thing when you blit it.
Having to calculate how big that temporary canvas should be, might be
tricky for the author. In the flash world, the movieclip's "canvas" is
calculated automatically by unioning all the drawing operators.

Rik

[David Geary-3]

On Mon, Jul 16, 2012 at 2:02 PM, Ashley Gullen <ashley@...> wrote:

> I'd like to bring up this subject again especially now that first
> implementations are starting to appear.
>
> IMO the big use case here is games - the CSS filters are great for
> interesting visual effects.  However there doesn't seem to be a way to use
> them in canvas rendering, other than applying the effect to an entire
> canvas. Games typically want to apply effects to individual objects
> (meaning individual drawImage() calls), and there is no good way to do
> this.  Stacking separate canvas elements is out of the question, because it
> makes Z ordering with effects impossible.  Consider trying to overlay an
> image with no effect on top of an image with an effect.  Also consider the
> fact canvas has compositing modes like "lighter" and "destination-out", but
> CSS filters do not provide these. This makes it impossible to combine CSS
> filters and composite modes. An example is displaying an additive blended
> explosion (typical in games) on top of an image with a blur CSS filter,
> which seems to be impossible to achieve at all.
>

Forcing developers to use CSS with Canvas to get high-level *graphics*
functionality is just plain wrong. If anything, it's completely backwards.
Why do we arbitrarily restrict high-level graphics functionality such as
filters and composite modes to individual technologies like CSS and Canvas?
I'm completely unaware of the advantages of such an approach. The term "CSS
filters" is absurd.

Filters are an important high-level graphics capability that should be
available to any HTML5 technology that chooses to incorporate them. I agree
with Ashley, let's get them into Canvas.

One way to define this is to specify that drawImage(), when passed another

> canvas as a parameter, must take in to account the canvas' 'filter' CSS
> property.  So to draw an image with a blur you'd render using an
> intermediate canvas, e.g.
>
> tempcanvascontext.drawImage(myimage, 0, 0);
> tempcanvas.style.filter = "blur(10px)";
> gamecanvascontext.drawImage(tempcanvas, 0, 0); // draws with blur
>
> Another way would be just to add a 'filter' property to the 2D context,
> e.g.:
>
> gamecanvascontext.filter = "blur(10px)";
> gamecanvascontext.drawImage(myimage, 0, 0);
>
> This would also be extremely powerful if custom CSS shaders are also
> supported, allowing for user-written effects in the canvas 2D context.
>
> Effects should should apply to all drawing operations for consistency,
> including lines, paths, rectangles and patterns.
>

I like the filter attribute on the context, provided that it's part of the
state saved by save():

    gamecanvascontext.drawImage(...); // image drawn normally

    gamecanvascontext.save();

    gamecanvascontext.filter = '...';
    gamecanvascontext.drawImage(...); // image drawn w/filter

    gamecanvascontext.restore();

    gamecanvascontext.drawImage(...); // image drawn normally

The default filter could be a no-op, which would be similar in behavior to
the default clipping region (they would both do nothing).


> I have no idea if this is easy for implementers (would appreciate comments
> on that), but hopefully the CSS filter rendering can be recycled with
> drawImage().
>
> Another argument is that you should just use WebGL and write shaders for
> advanced effects.
>

It's a poor argument, IMO. We should leave 3D for WebGL, but make advanced
effects available to all interested technologies.


>  This is an option, but given that a filter effect can be applied to an
> entire canvas, it seems a waste not to enable it for individual draw calls,
> especially given the 2D context is considerably easier and quicker to code
> for.
>

Agreed.


David

>
> Ashley Gullen
> Scirra.com
>
>
> On 25 January 2012 16:26, Tab Atkins Jr. <jackalmage@...> wrote:
>
>> On Wed, Jan 25, 2012 at 6:41 AM, David Geary <david.mark.geary@...>
>> wrote:
>> > On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin <cmarrin@...>
>> wrote:
>> >> Adding filter functions to canvas would require you to re-render the
>> items
>> >> for every filter change and you'd have to animate it all yourself.
>> >
>> > Sure, but you must create a superfluous canvas for each set of images
>> that
>> > you animate, and invoke an entirely different technology to apply the
>> > filter. You must  make sure that those superfluous canvases have
>> > transparent backgrounds, no borders, and have the correct Z order so
>> they
>> > appear over, and not under, the primary canvas for the application. And
>> I'm
>> > sure there are other gotchas to this hybrid approach that don't
>> immediately
>> > come to mind.
>> >
>> > I'd much rather use the filtering underlying API and control the
>> rendering
>> > and animation myself.
>>
>> Yes, it's effectively creating an ad-hoc retained-mode API out of
>> multiple <canvas> elements solely so it can apply filtering.
>>
>> (Using multiple backing canvases to sprite things is a reasonable
>> performance hack, but I don't think it should be required for basic
>> functionality.)
>>
>> ~TJ
>>
>
>

[Rik Cabanier-2]

On Thu, Jul 26, 2012 at 11:42 AM, David Geary <david.mark.geary@...>wrote:

> On Mon, Jul 16, 2012 at 2:02 PM, Ashley Gullen <ashley@...> wrote:
>
> > I'd like to bring up this subject again especially now that first
> > implementations are starting to appear.
> >
> > IMO the big use case here is games - the CSS filters are great for
> > interesting visual effects.  However there doesn't seem to be a way to
> use
> > them in canvas rendering, other than applying the effect to an entire
> > canvas. Games typically want to apply effects to individual objects
> > (meaning individual drawImage() calls), and there is no good way to do
> > this.  Stacking separate canvas elements is out of the question, because
> it
> > makes Z ordering with effects impossible.  Consider trying to overlay an
> > image with no effect on top of an image with an effect.  Also consider
> the
> > fact canvas has compositing modes like "lighter" and "destination-out",
> but
> > CSS filters do not provide these. This makes it impossible to combine CSS
> > filters and composite modes. An example is displaying an additive blended
> > explosion (typical in games) on top of an image with a blur CSS filter,
> > which seems to be impossible to achieve at all.
> >
>
> Forcing developers to use CSS with Canvas to get high-level *graphics*
> functionality is just plain wrong. If anything, it's completely backwards.
> Why do we arbitrarily restrict high-level graphics functionality such as
> filters and composite modes to individual technologies like CSS and Canvas?
> I'm completely unaware of the advantages of such an approach. The term "CSS
> filters" is absurd.
>

I think Ashley's point was to make CSS shaders-like functionality available
in Canvas.

>
> Filters are an important high-level graphics capability that should be
> available to any HTML5 technology that chooses to incorporate them. I agree
> with Ashley, let's get them into Canvas.
>
> One way to define this is to specify that drawImage(), when passed another
> > canvas as a parameter, must take in to account the canvas' 'filter' CSS
> > property.  So to draw an image with a blur you'd render using an
> > intermediate canvas, e.g.
> >
> > tempcanvascontext.drawImage(myimage, 0, 0);
> > tempcanvas.style.filter = "blur(10px)";
> > gamecanvascontext.drawImage(tempcanvas, 0, 0); // draws with blur
> >
> > Another way would be just to add a 'filter' property to the 2D context,
> > e.g.:
> >
> > gamecanvascontext.filter = "blur(10px)";
> > gamecanvascontext.drawImage(myimage, 0, 0);
> >
> > This would also be extremely powerful if custom CSS shaders are also
> > supported, allowing for user-written effects in the canvas 2D context.
> >
> > Effects should should apply to all drawing operations for consistency,
> > including lines, paths, rectangles and patterns.
> >
>
> I like the filter attribute on the context, provided that it's part of the
> state saved by save():
>
>     gamecanvascontext.drawImage(...); // image drawn normally
>
>     gamecanvascontext.save();
>
>     gamecanvascontext.filter = '...';
>     gamecanvascontext.drawImage(...); // image drawn w/filter
>
>     gamecanvascontext.restore();
>
>     gamecanvascontext.drawImage(...); // image drawn normally
>
> The default filter could be a no-op, which would be similar in behavior to
> the default clipping region (they would both do nothing).
>

This looks very reasonable.

On another note, wouldn't it be nice if you could add a grouping operator
such as this:

gamecanvascontext.filter = '...';
gamecanvascontext.beginGroup();
... // lots of drawing operators
gamecanvascontext.endGroup();

 and have everything in that group at endGroup time?

>
> > I have no idea if this is easy for implementers (would appreciate
> comments
> > on that), but hopefully the CSS filter rendering can be recycled with
> > drawImage().
> >
> > Another argument is that you should just use WebGL and write shaders for
> > advanced effects.
> >
>
> It's a poor argument, IMO. We should leave 3D for WebGL, but make advanced
> effects available to all interested technologies.
>
>
> >  This is an option, but given that a filter effect can be applied to an
> > entire canvas, it seems a waste not to enable it for individual draw
> calls,
> > especially given the 2D context is considerably easier and quicker to
> code
> > for.
> >
>
> Agreed.
>
>
> David
>
>
> >
> > Ashley Gullen
> > Scirra.com
> >
> >
> > On 25 January 2012 16:26, Tab Atkins Jr. <jackalmage@...> wrote:
> >
> >> On Wed, Jan 25, 2012 at 6:41 AM, David Geary <
> david.mark.geary@...>
> >> wrote:
> >> > On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin <cmarrin@...>
> >> wrote:
> >> >> Adding filter functions to canvas would require you to re-render the
> >> items
> >> >> for every filter change and you'd have to animate it all yourself.
> >> >
> >> > Sure, but you must create a superfluous canvas for each set of images
> >> that
> >> > you animate, and invoke an entirely different technology to apply the
> >> > filter. You must  make sure that those superfluous canvases have
> >> > transparent backgrounds, no borders, and have the correct Z order so
> >> they
> >> > appear over, and not under, the primary canvas for the application.
> And
> >> I'm
> >> > sure there are other gotchas to this hybrid approach that don't
> >> immediately
> >> > come to mind.
> >> >
> >> > I'd much rather use the filtering underlying API and control the
> >> rendering
> >> > and animation myself.
> >>
> >> Yes, it's effectively creating an ad-hoc retained-mode API out of
> >> multiple <canvas> elements solely so it can apply filtering.
> >>
> >> (Using multiple backing canvases to sprite things is a reasonable
> >> performance hack, but I don't think it should be required for basic
> >> functionality.)
> >>
> >> ~TJ
> >>
> >
> >
>

[Ashley Gullen]

>
> On another note, wouldn't it be nice if you could add a grouping operator
> such as this:
>
> gamecanvascontext.filter = '...';
> gamecanvascontext.beginGroup();
> ... // lots of drawing operators
> gamecanvascontext.endGroup();
>
>  and have everything in that group at endGroup time?
>

 Do you mean applying an effect to multiple draw operations?  Usually that
is achieved with rendering to an offscreen canvas, then rendering that with
the effect.

Ashley

[Rik Cabanier-2]

On Sat, Jul 28, 2012 at 1:58 PM, Ashley Gullen <ashley@...> wrote:

> On another note, wouldn't it be nice if you could add a grouping operator
>> such as this:
>>
>> gamecanvascontext.filter = '...';
>> gamecanvascontext.beginGroup();
>> ... // lots of drawing operators
>> gamecanvascontext.endGroup();
>>
>>  and have everything in that group at endGroup time?
>>
>
>  Do you mean applying an effect to multiple draw operations?
>

True, but you would have to know the size of the offscreen canvas which is
sometimes hard.
I'm unsure what happens if you scale or rotate that offscreen canvas. Will
the artwork and text antialias correctly? How does the up/downsampling
happen?


> Usually that is achieved with rendering to an offscreen canvas, then
> rendering that with the effect.
>

True, but you would have to know the size of the offscreen canvas which is
sometimes hard.
I'm unsure what happens if you scale or rotate that offscreen canvas. Will
the artwork and text antialias correctly? How does the up/downsampling
happen?

[Ashley Gullen]

Re: beginGroup()/endGroup(): I assume browsers would implement it as an
offscreen canvas anyway, so it would be better to write a JS library to
take care of it for you rather than requiring a browser feature for that.

You would not need to rotate or scale the off-screen canvas.  You'd make it
the size of the main canvas, draw everything with all the rotation/scaling
you want, then just draw it over the main canvas at (0, 0) with 100% scale.
 This will not affect antialiasing or artwork compared to just drawing it
directly to the main canvas.  Fancier implementations can work out the
changed bounding box and only draw that with the effect for efficiency.

Re: CORS - good point.  Perhaps we should disallow custom shaders until
this is figured out better (presumably it would have to be done the same
way as WebGL).  We can still add the stock CSS filter effects like blur,
grayscale, contrast etc. without any CORS concern, though.

Re: bounding boxes - I'm not sure why this needs to be included?  CSS
filters are smart enough to work out adjusted bounding boxes for HTML
images and divs, so can't the drawImage() call also work out the adjusted
bounding box necessary?  If the bounding box really must be separately
provided for some reason, then perhaps there could be a drawImage()
overload that also accepts a CSS filter string (e.g. "blur(10px)") and a
bounding box parameter?

Ashley


On 29 July 2012 00:27, Rik Cabanier <cabanier@...> wrote:

>
>
> On Sat, Jul 28, 2012 at 1:58 PM, Ashley Gullen <ashley@...> wrote:
>
>> On another note, wouldn't it be nice if you could add a grouping operator
>>> such as this:
>>>
>>> gamecanvascontext.filter = '...';
>>> gamecanvascontext.beginGroup();
>>> ... // lots of drawing operators
>>> gamecanvascontext.endGroup();
>>>
>>>  and have everything in that group at endGroup time?
>>>
>>
>>  Do you mean applying an effect to multiple draw operations?
>>
>
> True, but you would have to know the size of the offscreen canvas which is
> sometimes hard.
> I'm unsure what happens if you scale or rotate that offscreen canvas. Will
> the artwork and text antialias correctly? How does the up/downsampling
> happen?
>
>
>> Usually that is achieved with rendering to an offscreen canvas, then
>> rendering that with the effect.
>>
>
> True, but you would have to know the size of the offscreen canvas which is
> sometimes hard.
> I'm unsure what happens if you scale or rotate that offscreen canvas. Will
> the artwork and text antialias correctly? How does the up/downsampling
> happen?
>

[David Geary-3]

It looks like there is general agreement that CSS filters should be added
to Canvas. Now how do we make it happen?


david

On Sun, Jul 29, 2012 at 6:10 AM, Ashley Gullen <ashley@...> wrote:

> Re: beginGroup()/endGroup(): I assume browsers would implement it as an
> offscreen canvas anyway, so it would be better to write a JS library to
> take care of it for you rather than requiring a browser feature for that.
>
> You would not need to rotate or scale the off-screen canvas.  You'd make
> it the size of the main canvas, draw everything with all the
> rotation/scaling you want, then just draw it over the main canvas at (0, 0)
> with 100% scale.  This will not affect antialiasing or artwork compared to
> just drawing it directly to the main canvas.  Fancier implementations can
> work out the changed bounding box and only draw that with the effect for
> efficiency.
>
> Re: CORS - good point.  Perhaps we should disallow custom shaders until
> this is figured out better (presumably it would have to be done the same
> way as WebGL).  We can still add the stock CSS filter effects like blur,
> grayscale, contrast etc. without any CORS concern, though.
>
> Re: bounding boxes - I'm not sure why this needs to be included?  CSS
> filters are smart enough to work out adjusted bounding boxes for HTML
> images and divs, so can't the drawImage() call also work out the adjusted
> bounding box necessary?  If the bounding box really must be separately
> provided for some reason, then perhaps there could be a drawImage()
> overload that also accepts a CSS filter string (e.g. "blur(10px)") and a
> bounding box parameter?
>
> Ashley
>
>
> On 29 July 2012 00:27, Rik Cabanier <cabanier@...> wrote:
>
>>
>>
>> On Sat, Jul 28, 2012 at 1:58 PM, Ashley Gullen <ashley@...> wrote:
>>
>>> On another note, wouldn't it be nice if you could add a grouping
>>>> operator such as this:
>>>>
>>>> gamecanvascontext.filter = '...';
>>>> gamecanvascontext.beginGroup();
>>>> ... // lots of drawing operators
>>>> gamecanvascontext.endGroup();
>>>>
>>>>  and have everything in that group at endGroup time?
>>>>
>>>
>>>  Do you mean applying an effect to multiple draw operations?
>>>
>>
>> True, but you would have to know the size of the offscreen canvas which
>> is sometimes hard.
>> I'm unsure what happens if you scale or rotate that offscreen canvas.
>> Will the artwork and text antialias correctly? How does the up/downsampling
>> happen?
>>
>>
>>> Usually that is achieved with rendering to an offscreen canvas, then
>>> rendering that with the effect.
>>>
>>
>> True, but you would have to know the size of the offscreen canvas which
>> is sometimes hard.
>> I'm unsure what happens if you scale or rotate that offscreen canvas.
>> Will the artwork and text antialias correctly? How does the up/downsampling
>> happen?
>>
>
>

[Rik Cabanier-2]

File a bug on it:
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG
Describe what you want to see. Ie a new filter property that take the same
argument as a CSS filter (
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction )

On Thu, Aug 16, 2012 at 8:52 AM, David Geary <david.mark.geary@...>wrote:

> It looks like there is general agreement that CSS filters should be added
> to Canvas. Now how do we make it happen?
>
>
> david
>
>
> On Sun, Jul 29, 2012 at 6:10 AM, Ashley Gullen <ashley@...> wrote:
>
>> Re: beginGroup()/endGroup(): I assume browsers would implement it as an
>> offscreen canvas anyway, so it would be better to write a JS library to
>> take care of it for you rather than requiring a browser feature for that.
>>
>> You would not need to rotate or scale the off-screen canvas.  You'd make
>> it the size of the main canvas, draw everything with all the
>> rotation/scaling you want, then just draw it over the main canvas at (0, 0)
>> with 100% scale.  This will not affect antialiasing or artwork compared to
>> just drawing it directly to the main canvas.  Fancier implementations can
>> work out the changed bounding box and only draw that with the effect for
>> efficiency.
>>
>> Re: CORS - good point.  Perhaps we should disallow custom shaders until
>> this is figured out better (presumably it would have to be done the same
>> way as WebGL).  We can still add the stock CSS filter effects like blur,
>> grayscale, contrast etc. without any CORS concern, though.
>>
>> Re: bounding boxes - I'm not sure why this needs to be included?  CSS
>> filters are smart enough to work out adjusted bounding boxes for HTML
>> images and divs, so can't the drawImage() call also work out the adjusted
>> bounding box necessary?  If the bounding box really must be separately
>> provided for some reason, then perhaps there could be a drawImage()
>> overload that also accepts a CSS filter string (e.g. "blur(10px)") and a
>> bounding box parameter?
>>
>> Ashley
>>
>>
>> On 29 July 2012 00:27, Rik Cabanier <cabanier@...> wrote:
>>
>>>
>>>
>>> On Sat, Jul 28, 2012 at 1:58 PM, Ashley Gullen <ashley@...>wrote:
>>>
>>>> On another note, wouldn't it be nice if you could add a grouping
>>>>> operator such as this:
>>>>>
>>>>> gamecanvascontext.filter = '...';
>>>>> gamecanvascontext.beginGroup();
>>>>> ... // lots of drawing operators
>>>>> gamecanvascontext.endGroup();
>>>>>
>>>>>  and have everything in that group at endGroup time?
>>>>>
>>>>
>>>>  Do you mean applying an effect to multiple draw operations?
>>>>
>>>
>>> True, but you would have to know the size of the offscreen canvas which
>>> is sometimes hard.
>>> I'm unsure what happens if you scale or rotate that offscreen canvas.
>>> Will the artwork and text antialias correctly? How does the up/downsampling
>>> happen?
>>>
>>>
>>>> Usually that is achieved with rendering to an offscreen canvas, then
>>>> rendering that with the effect.
>>>>
>>>
>>> True, but you would have to know the size of the offscreen canvas which
>>> is sometimes hard.
>>> I'm unsure what happens if you scale or rotate that offscreen canvas.
>>> Will the artwork and text antialias correctly? How does the up/downsampling
>>> happen?
>>>
>>
>>
>