On Thu, Feb 24, 2011 at 6:15 PM, Chris Lilley <chris@w3.org> wrote: > 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. > I asked our GPU people if they can take a look at this since I'm not an expert on what's possible. > > > 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. > > That seems reasonable. A browser might use something like PixelBender under the hood to create the filter graph or render the filter in software. RikReceived on Monday, 28 February 2011 15:17:23 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:56 UTC