Re: [AD] About Elias' bug

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> As a result, I'm not sure anymore about the speed gain with a prepare
> function.

I've coded the 24->15 prepare function.
Here are the results in blits/s (P200, DirectX 640x480):

                       24->15 CC_TOTAL   24->15 CC_KEEP_TRANS
Allegro 3.9.37 CVS                43.5       n/a
blit.c.diff                             31.6      27.7
alt-blit.c.diff                        43.7      0.6
prepare()                            43.6      21.4

The prepare function approach seems to be interesting for truecolor to
hicolor conversion: no speed sacrifice in 'normal' conversion mode, a little
bit faster ;-) than the very generic function from the alt-blit.c.diff
patch.

However, this approach is a little trickier to implement for conversion to
paletted modes. If the RGB mapping table has been set up, that should be
feasible but otherwise...

Moreover, it turns out that we don't have to modify every conversion
routine: the current code works fine for ascendant conversions, except for
256 to higher color depths. But in this case, it is sufficient to tweak a
little the palette.

So only remain descendant conversions. As you noticed it, the dithering code
is already slow, using a per-pixel test costs virtually nothing (2%
according to my test).
16->15 and 32->24 are already ok.
For other routines (15->8, 16->8, 24->8, 24->15, 24->16, 32->8, 32->15,
32->16), I think we could simply duplicate the code and use your initial
method.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx