| Re: [AD] About Elias' bug |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> > 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.
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)
43.7/0.6 = 73 times fewer blits/s.
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 ?
Anyway, your prepare() seems to be quite fast. I was going to do a
getpixel() on every pixel in the source bitmap inside prepare(), so mine
would have been slower. I assume you had to create a temp bitmap, but
this seems to be a lot faster than i thought. And when you say you coded
the 24->15 function, does it mean you need a prepare() for every
descendant conversion ?
> 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...
Well, without the mapping table the current code is extremely slow as
well..
>
> 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.
Yes, my original problem only was with descendant conversion. I saw that
the best_fit_color() function already checks for color (63,0,63) and
index 0 in some way .. so I guess someone already had a similiar problem
once but did only partly fix it.
>
> 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.
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. And I
think blit() doesn't handle alpha bitmaps right now at all so they are
the same as 24.
> 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.
I thought that's where the prepare() was going to be used ?
Elias Pschernig