Re: [AD] improvements on alpha blending...

[Sven Sandberg <ssven.geo@xxxxxxxxxx>]

Javier González wrote:
> Basically yes, but I think 3 lookups + 3 bits shift
> per pixel is always faster than 6 multiplications, 3
> substractions, 3 bit shifts and 6 divisions using
> decimals per pixel :)

But Allegro doesn't use the algorithm that you
describe! AFAICS none of the functions in colblend.c
uses as much as 6 multiplications, and all divisions
are by powers of two (except for some that use
rgb_to_hsv(), but they don't count since they are so
slow anyway :-). It might still be faster to optimize
Allegro by copying the blenders to a hard-coded inner
loop though.

I still think there's room for optimizations though,
eg.:
 - Replace all `/ 256' by `>> 8' (the compiler can't
do this automatically because x>>8 != x/256 if x<0).
 - In burn and difference blenders, store the results
of get[rgb]*() in temporary variables, since the MAX()
and ABS() macros use their arguments several times and
will expand so that they call get[rgb]*() more than
once.
 - In all blenders that use get[rgb][15|16](), the
color values will be scaled to the range 0...256 and
then scaled back in the call to makecol(). This is
unnecessary, instead we can shift out the values
directly.

Bob, the inner loop of your routine looks very nice,
why not copy it to the appropriate blender in
colblend.c? The same optimizations could also be used
for other color depths as well.

Sven

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/