#10065 NORM Not Tri: SuperVampireNinjaZero unresponsive on 1.5-64

[Zarro Boogs per Child]

#10065: SuperVampireNinjaZero unresponsive on 1.5-64
------------------------------------+---------------------------------------
           Reporter:  bert          |       Owner:                                    
               Type:  defect        |      Status:  new                               
           Priority:  normal        |   Milestone:  Not Triaged                       
          Component:  not assigned  |     Version:  1.5 Software Build os64 aka 10.1.0
         Resolution:                |    Keywords:                                    
        Next_action:  never set     |    Verified:  0                                 
Deployment_affected:                |   Blockedby:                                    
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by Quozl):

 Tested on XO-1.5 build 112.

 While at the initial menu, the application consumes 50% of available CPU
 resource, and the X server is consuming the other 50%.

 Response to the keyboard keys is either delayed or missing.  If the
 keyboard keys are pressed and released very slowly, then the application
 responds properly.  This suggests the keys are being examined
 infrequently; maybe once every half second.

 An strace of the process shows:
  * the CPU time is being spent in user space code, not in system calls,
  * a call to select(2) is being made with a zero timeout, requesting
 activity on file descriptor 3, and this is returning no activity despite
 keyboard input, so this file descriptor is probably not relevant,
  * calls to poll(2) are being made with an infinite timeout, on file
 descriptor 4, and the reads and writes of the file descriptor suggest this
 is the X file descriptor, and activity occurs roughly every half second,
 and the activity rate does not seem to increase with keyboard actions,
  * the total time spent in system calls is quite low compared to the real
 time spent by the application, which correlates to the 50% CPU utilisation
 seen.

 Using gdb to obtain several backtraces, the following is seen, based on
 frequency:
  * run() -> render() -> endFrame() -> SDL_UpdateRects() ->
 SDL_LowerBlit(), showing that the application renders frames as fast as it
 can, not necessarily waiting for keyboard input,
  * run() -> render() -> endFrame() -> SDL_UpdateRects() -> XSync() ->
 poll(), the X server is certainly slowing the application's drawing,
  * run() -> render() -> DisplayObject::render() -> Sprite::render() ->
 SDLRenderer::renderTexture() -> SDL_UpperBlit() -> SDL_LowerBlit(), shows
 the application is managing sprite objects during the menu.

 Conclusion: the application is SDL and X performance bound on this
 platform.  This may relate to the bit depth of the X server, which changed
 from XO-1 (16) to XO-1.5 (24).

-- 
Ticket URL: <http://dev.laptop.org/ticket/10065#comment:2>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system