I have a Cairo application that is using Pixman to composite a semantically opaque image by scaling a bunch of source images in RGB24 format. If the target surface is also RGB24 format, then it is very fast and uses fast_composite_scaled_nearest_8888_8888_cover_SRC. But if the target surface is the ARGB32 format, then it takes almost three times as long and uses just fast_composite_scaled_nearest.
If I had a choice, I would always make the destination surface in RGB24 format, but unfortunately it is being created as ARGB32 by another library which I don't control, so my application is taking the slow path. I want to improve it so that the performance in the RGB24 -> ARGB32 case is approximately as good as the RGB24 -> RGB24 case, if possible. My idea for how to go about this is to add a x888_8888 fast-path to Pixman for RGB24 -> ARGB32 that does the same thing as the 8888_8888 path but sets all the destination alpha bytes to 0xFF. But before I try coding it I wanted to ask here if anyone has any other suggestions or knows of any "gotchas" with this approach. Comments? Tristan _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
