Re: [AD] About Elias' bug

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> 0.6 blits/s .. It means, it takes more than a second to do a
> getpixel/putpixel pair on every pixel in the bitmap. (The conversion
> 24->15 takes no time compared to that probably)

I have a very old machine :-) And I can see the bitmap drawing itself
onto the screen...

> I only get a difference from 416.4 to 58.1 = 7 times fewer blits with my
> test program for 24->15 and the alt-blit.c.diff - But I was only using a
> 256x256 bitmap and a P3-500. Still I don't understand how it could run
> that slow.. did you run it on a video bmp ?

No, I used your pink.c test.

> I assume you had to create a temp bitmap,

Yes.

> And when you say you coded the 24->15 function, does it mean
> you need a prepare() for every descendant conversion ?

Yes again, it's a macro, basically a stripped down version of
CONVERT_BLIT().

> Well, without the mapping table the current code is extremely slow as
> well..

Then we could request that the mapping table was set up.

> Do 16bit modes always have the extra bit for green ? If so, then of
> course they are using the same mask color, so there is no problem.

Afaik, yes.

> I thought that's where the prepare() was going to be used ?

Since prepare() are basically macros similar to CONVERT_BLIT(), we would
duplicate the code for those functions anyway.
So either we use prepare() macros for every routine, including for
conversion to 8-bit, or we duplicate the code and use your method (that
seems to be a little faster).

--
Eric Botcazou
ebotcazou@xxxxxxxxxx