[Pixman] RGB24 -> ARGB32 performance
siarhei.siamashka at gmail.com
Fri Jul 15 14:08:31 PDT 2011
On Fri, Jul 15, 2011 at 9:53 PM, Tristan Schmelcher
<tschmelcher at google.com> wrote:
> 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
Have you tried alternatively converting your opaque source images to
ARGB32 format? This approach may have some advantages.
> 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.
Yes, this is how pixman development is done at the moment. One finds
something that is slow and adds new special fast paths for it. I have
also attached a patch which should add the needed entries to the fast
path tables. Probably this is what you are intending to get.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3447 bytes
Desc: not available
More information about the Pixman