[cairo] More info about fbCompositeCopyAreammx

Frédéric Plourde frederic.plourde at polymtl.ca
Thu Mar 27 14:53:02 PDT 2008

Vladimir Vukicevic a écrit :
> On Mar 27, 2008, at 11:51 AM, Frédéric Plourde wrote:
>> Remember that issue you brought up about subimage_copy with 512X512 
>> which made things slower ?
>> I've got some more news about it...
>> Since Soeren questionned the precision of giving perf results with 
>> only a small number of iterations, I've used a minimum of 100 
>> iterations on my perf tests.
>> Take a look at the newest results about "subimage_copy"...
>> http://pastebin.mozilla.org/383418
>> First group of results shows NO GAIN between  pre-mmx and post-mmx 
>> versions
>> except for the 512X512 case alone, which shows 58% speedup... that's 
>> weird
>> The second group of results shows perf GAINS between :  before 
>> applying my patch and after applying my "fbCompositeCopyArea" patch
>> But these gains, as you noticed earlier, seem to fade out as the 
>> image scales up.
>> I'll investigate some more about that, but for now, I think the patch 
>> "pixman_OPT_MMX_addFastPath_to_fbCompositeCopyAreammx.patch" is worth 
>> it.
> Sounds good to me -- Soeren, adding an x8r8g8b8 -> a8r8g8b8 SOURCE 
> path being a Copy sounds sane, right?  Fred, I notice that your patch 
> only adds that path for the MMX case, but the same path can be added 
> for non-MMX also, I think.
>     - Vlad

By non-mmx, you mean the regular c_fast_paths, right ?... Then,  Yep, 
the optimization benefits there also, but it's been already done in the 
The fastpath function name is not named consistently with the mmx one 

see the
{ PIXMAN_OP_SRC, PIXMAN_a8r8g8b8,  PIXMAN_null,     PIXMAN_x8r8g8b8, 
fbCompositeSrc_8888xx888, 0 }, and
{ PIXMAN_OP_SRC, PIXMAN_a8b8g8r8,  PIXMAN_null,     PIXMAN_x8b8g8r8, 
fbCompositeSrc_8888xx888, 0 }, in pixman-pict.c
which both call function "fbCompositeSrc_8888xx888" that simply does the 
trick using memcpy(...) ;-)


More information about the cairo mailing list