Fishwars: Hoping Qt Can Blit Faster

First stop on the GUI framework search: PyQt4. Out of the gate it’s looking good. It’s simple to draw primitive shapes in an off-screen buffer and then rescale that image and blit a portion of it into a bare window. Restricting window size (minimum, maximum, granularity) is also a piece of cake.

Testing window resizing helped me decide to commit to x2 (double-size) pixels. I knew x4 would be too large but between x2 and x3 I wasn’t sure. x3, it turns out, causes a problem with maximized windows because many desktop sizes aren’t divisible by 3. x2 is sufficiently pixely, still leaves plenty of resolution for fine details, and it’s a safe bet for filling maximized windows properly even with window decorations and borders and the like.

I started putting together methods for scrolling/panning the contents of the window, and I hit a major problem. My CPU was burning. Panning at a steady pace with arrow keys ramps CPU load to maximum. This is a showstopper: simply blitting the scaled up image into the window at a high enough rate to make basic animation possible is a crippling load even without the additional work of actually drawing each new frame. This doesn’t sit right with me. This should be fast. It should be practically free. I have to fix this before I go any farther with Qt; if I can’t fix it I’ll have to try something completely different, maybe PyGTK.

The crippling blit GUI prototype: qtinky20100706.py

This entry was posted in Uncategorized and tagged , . Bookmark the permalink.