[Pixman] RGB24 -> ARGB32 performance

[Siarhei Siamashka]

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
> possible.

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.
>
> Comments?

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.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-C-fast-path-for-scaled-src_x888_8888-with-nearest-fi.patch
Type: text/x-patch
Size: 3447 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20110716/3c865f7e/attachment.bin>