performance work

[Jordan Crouse]

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