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

 Assembly is wonderful and all, but it's a mighty big leap from Python with
 repeated creation/destruction of various objects and contexts. The middle
 ground, plain C, is far easier to maintain than assembly.

 Assembly or not, I might be able to help. (starting from C, not Python)
 Does this activity run (crawl) on B2 hardware? I recall something about
 the audio input being incompatible.

 My gut feeling, based on experience rather than the profiler data which
 you really need to get, is that you can gain a great deal by avoidance of
 redundant bulk memory writes and by paying attention to cache locality. I
 presume you are currently redrawing the whole thing each time, in color,
 and then sending it through all the normal layers. Consider keeping track
 of unused pixels within the display, perhaps with a granularity of 8x8 to
 128x128. Compare having the X server do bulk copies against using shared
 memory. (may interact with granularity and app usage) Consider using a
 palette within the app, 8 bits per pixel or less, expanding to the native
 pixels as they are written. Don't let pointer aliasing make your compiler
 do slow things; the C99 "restrict" keyword is your new friend.

 Be sure your FFT comes from the FFTW library, and that you have pre-
 computed wisdom when the laptop's OS is installed. Both /etc/fftw/wisdomf
 and /etc/fftw/wisdom should exist, and using fftw-wisdom-to-conf would be
 a good idea.

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