<br><br><div class="gmail_quote">On 16 July 2011 04:53, 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;">
On Sat, Jul 16, 2011 at 12:50 AM, Tristan Schmelcher<br>
<div class="im"><<a href="mailto:tschmelcher@google.com">tschmelcher@google.com</a>> wrote:<br>
> On 15 July 2011 14:08, Siarhei Siamashka <<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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>
>> Have you tried alternatively converting your opaque source images to<br>
>> ARGB32 format? This approach may have some advantages.<br>
><br>
> The source images come from the output of a video decoder. Converting them<br>
> would mean touching all the memory an extra time for every frame, so also<br>
> not very efficient.<br>
<br>
</div>OK, I just thought that these might have been some static images.<br>
<br>
But does this video decoder provide images directly in RGB24 format<br>
with no intermediate pass performing YUV to RGB conversion? Because a<br>
better place to set alpha channel to 0xFF and effectively get ARGB32<br>
images might be YUV->RGB converter code.</blockquote><div><br></div><div>Yeah, that was something else I considered, but it would have required a fair amount of refactoring. This patch was way simpler.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">There is also a stalled work<br>
providing adequate native YUV support in cairo/pixman, which might be<br>
the best solution for you.<br></blockquote><div><br></div><div>Cool. If that work were to be completed we would probably use it.</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>
>> 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>
><br>
> Heh, I coded up nearly the same thing moments ago. :)<br>
<br>
</div>Yeah, it's indeed not difficult at all. There is just one pitfall<br>
handling NONE repeat, which is a bit tricky because the pixels fetched<br>
from outside the source image have to be transparent even though RGB24<br>
image is itself fully opaque.<br></blockquote><div><br></div><div>Ahh, I see.</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>
> I tested your patch and it works great. The performance is indistinguishable<br>
> from RGB24 -> RGB24.<br>
> Thanks!<br>
<br>
</div>OK, then I'll push it to pixman git master in a few days if nobody<br>
complains. If you encounter any other cases of taking slow path in<br>
pixman on your workload, feel free to post bugreports or patches.<br></blockquote><div><br></div><div>Great, thanks again!</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>