SuperVampireNinjaZero unresponsive on 1.5-64

[bert]

Downloaded svnz-01.xo from http://www.supervampireninja.com/ 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.

[bert]

Also works fine in F11 on XO-1.

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

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

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