On 16 July 2011 04:53, Siarhei Siamashka <[email protected]>wrote:
> On Sat, Jul 16, 2011 at 12:50 AM, Tristan Schmelcher > <[email protected]> wrote: > > On 15 July 2011 14:08, Siarhei Siamashka <[email protected]> > > wrote: > >> > >> On Fri, Jul 15, 2011 at 9:53 PM, Tristan Schmelcher > >> <[email protected]> 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 >
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
