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

Re: Filter Templates

From: Chris Lilley <chris@w3.org>
Date: Fri, 25 Feb 2011 03:15:34 +0100
Message-ID: <1795874292.20110225031534@w3.org>
To: "Robert O'Callahan" <robert@ocallahan.org>
CC: Rik Cabanier <cabanier@gmail.com>, 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>
On Friday, February 25, 2011, 1:54:48 AM, Robert wrote:

ROC> On Fri, Feb 25, 2011 at 12:06 PM, Rik Cabanier <cabanier@gmail.com> wrote:
ROC>  Is it possible to implement hardware acceleration for SVG
ROC> filters? I'm not an expert on the subject but it seems that some
ROC> of the filters would be very hard to write as a shaders.

There have been hardware-accelerated implementations of SVG filters. This was on an Texas Instruments chip, which was an Acorn ARM processor with integrated DSP, and was around 2004 or so.

At the time, we were trying to work out a suitable subset of filters suitable for mid-range (at that time) mobile devices. The feedback from BitFlash, who were doing the hardware accelerated implementation, was that "all of them are suitable for mobile". I conclude that they had at that time accellerated all of the filters.
ROC> Anyway, it doesn't really make sense to go off and define an
ROC> all-new standard because we think some SVG filters might not be
ROC> acceleratable on some hardware. As Dean pointed out, that will be
ROC> true for any adequately powerful filter API. We'll simply have to
ROC> fall back to a software implementation or refuse to apply the filter.

I agree.

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Friday, 25 February 2011 02:17:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC