Bug 27711 – SVG Filter need feColorMatrix implementation

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Dirk Schulze]

SVG Filter need feColorMatrix implementation

[Dirk Schulze]

Created attachment 33543 [details]
SVG feColorMatrix-implementation

This is the implementation  of feColorMatrix.

[Oliver Hunt]

Comment on attachment 33543 [details]
SVG feColorMatrix-implementation

Woo!  alas, the double casts here:
double red = (double)r, green = (double)g, blue = (double)b, alpha = (double)a;

are unnecessary

And I don't like having that switch in the middle of the main processing loop -- i'm not entirely sure what can be done to improve it short of something involving templates ;)

[Eric Seidel (no email)]

The switch could be pulled out into a wrapper and a const function pointer used instead.  The compiler should be able to optimize the jump with a const function pointer, no?

[Oliver Hunt]

I think not with gcc i don't think :D, i was thinking of templating on the operation type

[Dirk Schulze]

Created attachment 34041 [details]
SVG feColorMatrix-implementation

SVG feColorMatrix-implementation with templates.

[Eric Seidel (no email)]

Comment on attachment 34041 [details]
SVG feColorMatrix-implementation

Sigh.  We totally need Color accessors to:
127         srcPixelArray->get(pixelByteOffset, r);
 128         srcPixelArray->get(pixelByteOffset + 1, g);
 129         srcPixelArray->get(pixelByteOffset + 2, b);
 130         srcPixelArray->get(pixelByteOffset + 3, a);

Sigh.  I still think function pointers would be cleaner than templates.

I'll r+ this, but I definitely would prefer function pointers for this sort of thing.  Modern compilers should be able to handle the jump prediction.

[Adam Barth]

Assigned to krit for landing.

[Dirk Schulze]

landed in r46958.