#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 AlbertCahalan):

 Replying to [comment:7 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.

 That could be a good start, but I question "push the data" and it is
 important to be able to eliminate Cairo. Can the Python code just write to
 a memory block that the C code provides? That would be better.

 It should be possible for the C code to use a separate process. Sometimes
 this can help, despite the overhead.

 > 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.

 This is provably wrong, despite the FSF efforts to confuse people.

 For example, procps compiles on all Linux platforms. It doesn't need 250
 KB of slow shell scripts which check for useless stuff like a FORTRAN
 compiler. One can support MacOS and FreeBSD even, if one cares.

 If you tell me what it has to do, I can write a proper Makefile for you.

 > 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.

 Clean C code is easily modified to support those improvements, even when
 using relatively raw interfaces. (for bad C code... well don't blame the
 language!)

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