[Pixman] RGB24 -> ARGB32 performance

[Siarhei Siamashka]

On Sat, Jul 16, 2011 at 12:50 AM, Tristan Schmelcher
<tschmelcher at google.com> wrote:
> On 15 July 2011 14:08, Siarhei Siamashka <siarhei.siamashka at gmail.com>
> wrote:
>>
>> 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.
>
> The source images come from the output of a video decoder. Converting them
> would mean touching all the memory an extra time for every frame, so also
> not very efficient.

OK, I just thought that these might have been some static images.

But does this video decoder provide images directly in RGB24 format
with no intermediate pass performing YUV to RGB conversion? Because a
better place to set alpha channel to 0xFF and effectively get ARGB32
images might be YUV->RGB converter code. There is also a stalled work
providing adequate native YUV support in cairo/pixman, which might be
the best solution for you.

>> > 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.
>
> Heh, I coded up nearly the same thing moments ago. :)

Yeah, it's indeed not difficult at all. There is just one pitfall
handling NONE repeat, which is a bit tricky because the pixels fetched
from outside the source image have to be transparent even though RGB24
image is itself fully opaque.

> I tested your patch and it works great. The performance is indistinguishable
> from RGB24 -> RGB24.
> Thanks!

OK, then I'll push it to pixman git master in a few days if nobody
complains. If you encounter any other cases of taking slow path in
pixman on your workload, feel free to post bugreports or patches.

-- 
Best regards,
Siarhei Siamashka