SVG feComponentTransfer needs to be implemented
Created attachment 33662 [details] SVG Filter feComponentTransfer Implementation with look-up-table. This is a dramaticly speed up of feComponentTransfer.
Comment on attachment 33662 [details] SVG Filter feComponentTransfer Hum... I still think function pointers or templates would allow us to share much more code. Do we know that function pointers would be a slowdown?
Comment on attachment 33662 [details] SVG Filter feComponentTransfer Sad that we don't have a Color based get/set: 5 srcPixelArray->get(pixelByteOffset, r); 196 srcPixelArray->get(pixelByteOffset + 1, g); 197 srcPixelArray->get(pixelByteOffset + 2, b); 198 srcPixelArray->get(pixelByteOffset + 3, a); This should just be an array of these function pointers: 168 switch (channel) { 169 case 0: 170 transferFunction = redFunction(); 171 break; 172 case 1: 173 transferFunction = greenFunction(); 174 break; 175 case 2: 176 transferFunction = blueFunction(); 177 break; 178 case 3: 179 transferFunction = alphaFunction(); 180 break; 181 default: 182 break; 183 } probably quicker than a switch, and much, much less code. :) We need to find a way to share more of these for loops. I think that we should use function pointers indexed in an array by transferFunction.type.
Created attachment 34427 [details] SVG Filter feComponentTransfer with use of function pointer
Comment on attachment 34427 [details] SVG Filter feComponentTransfer clearing review tag. I'll upload a more efficient version after the patch on bug 28133 is ready.
Created attachment 35111 [details] SVG Filter feComponentTransfer Make use of some recently added methods in FilterEffect and CanvasPixelArray.
Comment on attachment 35111 [details] SVG Filter feComponentTransfer Clearing flags on attachment: 35111 Committed r47529: <http://trac.webkit.org/changeset/47529>
All reviewed patches have been landed. Closing bug.