Opened 5 years ago

Last modified 6 weeks ago

#10065 new defect

SuperVampireNinjaZero unresponsive on 1.5-64

Reported by: bert Owned by:
Priority: normal Milestone:
Component: not assigned Version: 1.5 Software Build os64 aka 10.1.0
Keywords: Cc: mikus
Blocked By: Blocking:
Deployments affected: Action Needed: never set
Verified: no


Downloaded svnz-01.xo from and tested on a 1.5 beta machine at os64. There are long delays, e.g. when pressing up/down in the menu.

No such delays on an XO-1 at os802.

Change History (7)

comment:1 Changed 5 years ago by bert

Also works fine in F11 on XO-1.

comment:2 Changed 5 years ago 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).

comment:3 Changed 5 years ago by mikus

  • Cc mikus added

comment:4 Changed 5 years ago by Quozl

Changing the bit depth of the X server to 16 causes a great improvement to game frame rate. This suggests the application is coded to prefer 16-bit surfaces, and should rather be coded to use the bit depth of the X server.

comment:5 Changed 5 years ago by Quozl

Running the application on XO-1.5 with 16-bit X server is still significantly slower than running it on XO-1 with 16-bit X server.

Ticket #9325 may relate, since it points out a ratio of seven between XO-1 and XO-1.5 full screen blits.

comment:6 Changed 5 years ago by Quozl

  • Milestone changed from Not Triaged to 1.5-software-later

comment:7 Changed 6 weeks ago by Quozl

  • Milestone 1.5-software-later deleted

Milestone 1.5-software-later deleted

Note: See TracTickets for help on using tickets.