RE: [AD] Potential color conversion bug

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2005-06-20 at 10:14 -0700, Robert Ohannessian wrote:
> 
> Sure, but then just make ddraw->vtable->blit_from_memory() call
> ddraw->vtable->blit_between_formats() if it can't do a blit with
> conversion at the same time.

Yes, of course. But I couldn't test that change myself, without
windows..

> 
> > So I'd
> > be for leaving the order, and adjusting AllegroGL's vtable, since it
> > seems to be the only case with problems.
> 
> So far...

True. I wouldn't be surprised if there are problems with video bitmaps
of different depth on all drivers. Actually.. AllegroGL may be the only
driver that supports them anyway.

> > 
> > Would there be any complication with just having AllegroGL's
> > blit_between_formats check if both bitmaps are video bitmaps, and in
> > that case bypass the color conversion?
> 
> 
> I'd need to duplicate (pretty much) the whole of blit() in AGL, since I
> need to support memory <-> video blits.
> 

Ok. I see no real problem then with changing the order, I guess - as
long as someone tests at least the common blit cases after the change
under windows. It's really a shame we have no better test program which
could just be run and check if anything went wrong :(

Oh, btw, I tried Peter's example code, but added this line:

printf ("%d -> %d\n", bitmap_color_depth(bm),
bitmap_color_depth(screen));

Now, the interesting results:
32 -> 32
mem 4.160000
32 -> 32
vid 12.340000

I.e., video bitmaps simply *are* slower with AllegroGL under Linux, even
if no color conversion at all is done. So, fixing this won't change
anything on the original problem that video bitmaps are slower.

Which almost makes me think, I somehow did something else wrong.. I'll
try to investigate more. Or is there any explanation so far?

-- 
Elias Pschernig