Krzysztof Kosiński wrote:
In this case it doesn't matter because the input values are limited to 0...255. We can use any multiplier we want - as long as the coeffs sum up to the value we use as the divisor, it will work correctly. There are many other cases where it won't, precisely because of the reason you mentioned (e.g. in blending, or when alpha is used as a coefficient) and then we can't avoid the division.
Well, I was speaking about avoiding the final multiplication and the use of floats: if you want to get 255 as final maximum starting from 256 (or 512, or 2^n), you either have to divide by 1,00392... (or 2,00784..., or some other float) or first you have to multiply by 255 and then shift-divide (by 8 or 9). Then, why not implicitly mutliply by 2^n in each partial coefficient so you sum up to 255*2^n, which are multiplications you must do and in this case can turn into integer multiplications rather than floats and without loss of final precision? If you sum up to 32768 (16 bits!) and then divide by 128 (>>7) and your result is '1' you get 256 that is over the limit of 255. But if you sum up to 32767 (or better 32640, both 15 bits so we could use one more bit for precision) you just have to >>7 and you're done. No floats, no final multiplitcation: just the final scale already taken into consideration in all preceeding calculations. And the difference between the two is only in considering 256 or 255 (or better, 2^n rather than (2^n)-1) as maximum. Indeed, it's really in this case that matters.
This way of doing calculations is typical of microcontollers and DSPs where performances do count a lot because you either need to be really fast (but really!) or you don't have enough resources for your application but you have to make it work anyway :) My opinion is that Inkscape could be faster than it is, or at least give the feeling that it is. Maybe some more attention to these details (because they are details, but many details make a whole) could help to improve performances.
Regards. Luca