[Pixman] RGB24 -> ARGB32 performance

[Tristan Schmelcher]

On 16 July 2011 04:53, Siarhei Siamashka <siarhei.siamashka at gmail.com>wrote:

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


Yeah, that was something else I considered, but it would have required a
fair amount of refactoring. This patch was way simpler.


> There is also a stalled work
> providing adequate native YUV support in cairo/pixman, which might be
> the best solution for you.
>

Cool. If that work were to be completed we would probably use it.


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

Ahh, I see.


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

Great, thanks again!


>
> --
> Best regards,
> Siarhei Siamashka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20110718/f113346c/attachment.htm>