Re: [AD] pink color conversion blit bug

["Elias Pschernig" <eliaspschernig@xxxxxxxxxx>]

>
> What does everyone think of this patch/feature?
>
> > In case the patch is accepted I guess I should add a note
> > about COLORCONV_TRANS_CARE to the documentation as well..
>
> Yes, please.  Try to make the meaning of "TRANS_CARE" more
> obvious (it took a while for me to get my head around it,
> actually :-)
>

Ok, i thought the test program would make obvious what it
does :) I added a note to set_color_conversion in allegro._tx,
I think it should explain what it does now.
I also think the name suggested by Javier González is better than mine, so
i changed the patch to use COLORCONV_KEEP_TRANS.

In case anyone is interested, i added timing to my test
program. Following are the results of some runs:
The numbers are in blits per second averaged through 10 seconds.

blit() before my patch:

             32->16   32->8   8->32
no dithering 466.8    5.6     233.6
   dithering 178.2    2.3     233.9

blit() with my patch:

             32->16   32->8   8->32
no dithering 292.6    5.7     236.5
   dithering 149.7    2.4     237.9

blit() with my patch and with COLORCONV_KEEP_TRANS:

             32->16   32->8   8->32
no dithering 258.3    5.3     238.3
   dithering 138.8    2.2     237.9

blit() without doing conversions should not be affected at all of course.

The 32->8 uses no map table so it doesn't say much, but i don't want to run
it again right now.. the 32->16 no dithering shows that after my patch
conversions are only running at about 60% compared to before. I didn't
expect the patch to have such a high impact on speed, it should only add
one bit-flag test to every pixel.

Attached is a patch containing the allegro._tx.diff, and the old patch with
the flag name changed..

Elias Pschernig

Attachment: blit.tar.gz
Description: GNU Zip compressed data