- From: Chris Lilley <chris@w3.org>
- Date: Fri, 25 Feb 2011 03:15:34 +0100
- 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:15:46 UTC