<br><br><div class="gmail_quote">On 15 July 2011 14:08, Siarhei Siamashka <span dir="ltr"><<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On Fri, Jul 15, 2011 at 9:53 PM, Tristan Schmelcher<br> <<a href="mailto:tschmelcher@google.com">tschmelcher@google.com</a>> wrote:<br> > I have a Cairo application that is using Pixman to composite a<br> > semantically opaque image by scaling a bunch of source images in RGB24<br> > format. If the target surface is also RGB24 format, then it is very<br> > fast and uses fast_composite_scaled_nearest_8888_8888_cover_SRC. But<br> > if the target surface is the ARGB32 format, then it takes almost three<br> > times as long and uses just fast_composite_scaled_nearest.<br> ><br> > If I had a choice, I would always make the destination surface in<br> > RGB24 format, but unfortunately it is being created as ARGB32 by<br> > another library which I don't control, so my application is taking the<br> > slow path. I want to improve it so that the performance in the RGB24<br> > -> ARGB32 case is approximately as good as the RGB24 -> RGB24 case, if<br> > possible.<br> <br> </div>Have you tried alternatively converting your opaque source images to<br> ARGB32 format? This approach may have some advantages.<br></blockquote><div><br></div><div>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.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > My idea for how to go about this is to add a x888_8888 fast-path to<br> > Pixman for RGB24 -> ARGB32 that does the same thing as the 8888_8888<br> > path but sets all the destination alpha bytes to 0xFF. But before I<br> > try coding it I wanted to ask here if anyone has any other suggestions<br> > or knows of any "gotchas" with this approach.<br> ><br> > Comments?<br> <br> </div>Yes, this is how pixman development is done at the moment. One finds<br> something that is slow and adds new special fast paths for it. I have<br> also attached a patch which should add the needed entries to the fast<br> path tables. Probably this is what you are intending to get.<br></blockquote><div><br></div><div>Heh, I coded up nearly the same thing moments ago. :)</div><div><br></div><div>I tested your patch and it works great. The performance is indistinguishable from RGB24 -> RGB24.</div> <div><br></div><div>Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br> --<br> Best regards,<br> <font color="#888888">Siarhei Siamashka<br> </font></blockquote></div><br>