Hi Jordan et al,

Thanks a lot for the advice. I'm forking this thread and will reply on 
the other one too.

One question here on your suggested methodology. Are you suggesting that 
we try those X composite hooks and then re-run the benchmark to see if 
it improves?


Is anyone interested in getting in to this X windows code?

We have some momentum now including a test bed and baseline results so 
it may be the right time to work on everybody's favorite bugaboo: 


Greg S

Jordan Crouse wrote:
> Greg Smith wrote:
>> Hi Jordan,
>> Looks like we made a little more progress on graphics benchmarking. 
>> See Neil's results below.
>> I updated the feature page with the test results so far:
>> http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
>> What's next?
>> Do we know enough now to target a particular section of the code for 
>> optimization?
> My previous email was pretty long, so I thought I would answer this last 
> question separately.   I can help guide you with the operations that are 
> slower with acceleration.   There may be other optimizations to be had 
> within cairo or elsewhere in the X world, but I'll have to leave those 
> to  people who understand that code better.
> The majority of the operations will probably be composite operations. 
> You will want to instrument the three composite hooks in the X driver 
> and their sub-functions:  lx_check_composite, lx_prepare_composite, and 
> lx_do_composite (in lx_exa.c).
> lx_check_composite is the function where EXA checks to see if we are 
> willing to do the operation at all - most of the acceleration rejects 
> should happen here. lx_prepare_composite is where we store the 
> information we need for the ensuing composite operation(s) - we can also 
> bail out here, but there is an incremental cost in leading EXA further 
> down the primrose path before rejecting it.  lx_do_composite() obviously 
> is where the operation happens.  You will want to concentrate on these 
> functions - instrument the code to figure out why we accept or reject an 
> operation and why we take so long in rejecting certain operations. 
> Profiling these functions may also help you figure out where we are 
> spending our time.
> So, in short - become one with the ErrorF() and good luck... :)
> Jordan
Devel mailing list

Reply via email to