#3438 HIGH First D: Optimize drawing code and response time of Measure Activity

[Zarro Boogs per Child]

#3438: Optimize drawing code and response time of Measure Activity
-------------------------------+--------------------------------------------
  Reporter:  arjs              |       Owner:  arjs                                    
      Type:  enhancement       |      Status:  new                                     
  Priority:  high              |   Milestone:  First Deployment, V1.0                  
 Component:  measure-activity  |     Version:                                          
Resolution:                    |    Keywords:  optimize drawing, response time, measure
  Verified:  0                 |  
-------------------------------+--------------------------------------------

Comment(by dcbw):

 You probably should still be using Cairo if you do it in C, so what you're
 really losing is Python overhead if you do that.  The best approach is to
 make a GTK widget in C that handles all the drawing, and then push the
 data to that widget (via GObject properties) in python.  Once you go with
 C, you then need a build system like autotools or setup tools for your
 activity though, because you need to compile the C bits on any platform,
 not just i386.  The C compliation bits _cannot_ be hardcoded makefiles.

 I'd suggest getting profiling results to figure out what's really slow.
 Second, you need to find out exactly how much of the screen you are
 redrawing with each update, and see if you can optimize that area further.
 You may be able to use the XDamage extension more intelligently than
 cairo/GTK, but that's questionable.

 There's also the trade-off between highly optimizing your activity's
 drawing versus forward compatibility and being able to take advantage of
 ongoing performance improvements in X, EXA, and Cairo.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3438#comment:7>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system