W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: Filter Templates

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 25 Feb 2011 13:36:27 -0800
Message-ID: <AANLkTikEF2buAT_i4bxBZ-kTyrh1zU0wwdLOtEdNVW0S@mail.gmail.com>
To: robert@ocallahan.org
Cc: Rik Cabanier <cabanier@adobe.com>, Cameron McCormack <cam@mcc.id.au>, Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>, Dean Jackson <dino@apple.com>
Hi Rob,

I asked our GPU experts to take a look at the SVG filter spec and they say
that at first glance most filters would be trivial to implement with the
possible exception of Turbulence.
After asking around, it turns out that Adobe had a complete GPU
implementation for filters back in 2004 so it should definitely be possible
on today's hardware.

Dean's proposal of a set of simple filters is still good. Browser vendors
can choose to layer them on top of SVG which is then accelerated
or directly on top of OpenGL or DirectX.

Rik

On Thu, Feb 24, 2011 at 4:54 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Feb 25, 2011 at 12:06 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> Is it possible to implement hardware acceleration for SVG filters? I'm not
>> an expert on the subject but it seems that some of the filters would be very
>> hard to write as a shaders.
>
>
> Which filters?
>
> Anyway, it doesn't really make sense to go off and define an all-new
> standard because we think some SVG filters might not be acceleratable on
> some hardware. As Dean pointed out, that will be true for any adequately
> powerful filter API. We'll simply have to fall back to a software
> implementation or refuse to apply the filter.
>
> But if there are particular aspects of SVG filters that make them difficult
> to accelerate, let's talk about that. I certainly agree they could use some
> improvement :-).
>
>
Received on Monday, 28 February 2011 15:17:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT