[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
I've just browsed the story. I think we should try to find a solution,
because transparency needs to be preserved through color conversion.
So far Elias has proposed two solutions:
- testing color value on a per-pixel basis: minimal amount of added code,
but huge slowdown for every blit() between color formats,
- brand new blit_keep_trans() function: in order not to duplicate the whole
blit.c file, the function has to be very generic, hence very slow.
I think we shouldn't bear the first solution in mind, because it
definitively costs too much.
Would it not be more efficient to use a two-pass color conversion process
for the COLORCONV_KEEP_TRANS mode rather than the very generic and very
slow blit_keep_trans() ?
There are only two colors in the source color space that we must take care
of: the transparency color (color 1) and the color which will give the
transparency color in the destination color space (color 2).
So the first pass would 'prepare' the bitmap by changing color 1 into color
2 and color 2 into any distinct color in the neighborhood. The second pass
would be the raw blit().
This would work unmodified for ascendant conversions. For descendant ones,
color 2 is of course not a single color but a cloud of colors.
--
Eric Botcazou
ebotcazou@xxxxxxxxxx