Saturday, October 23, 2010

tricks for good 2d rendering performance with pygame

pygame's API for initializing a display has a couple attractive sounding flags. Or at least, they sound attractive once you notice that updating your 320x240 window at 30fps is consuming all available cycles on your brand new Intel i9 CPU. They're HWSURFACE and DOUBLEBUF. Hardware surfaces and double buffering is how you make graphics fast, right?

Well... no. You probably can't get a hardware surface anyway, and double buffering is unlikely to help until you figure out how to have a window larger than 320x240 anyway.

What you really need to do to get reasonable rendering performance is make sure that any images you blit to the display have the same color depth. You can do this with the Surface.convert method (you get back a Surface when you load an image from a file, eg a png or a gif). Check the depth of your display surface and then convert your image surfaces to that depth (and just keep the converted versions). Blitting them will get hundreds of times faster.

It's a pretty simple thing, but it's easy to get distracted by HWSURFACE and not notice the depth mismatch (like I did for three days).

Eugh. Good to know. Though this begs the question why pygame.image.load doesn't just pick the most suitable depth. :) I suppose it has something to do with the fact that you can load an image before you initialize the display, but you can't convert an image until after you initialize the display. But then, why that arbitrary difference?

Probably because you might want to do something with an image other than blit it (also there's two ways to convert: .convert and .convert_alpha, picking either to be automatic would annoy people who want the other behavior), like say if I want to load a greyscale image to use as a heightmap: I'd like it to stay as a 8bpp image, not get converted to 32bpp because the user happens to be using a 32bpp display.

About Me

I'm a software professional with over 15 years industry experience ranging from startups (with as few as four people) to multinational banks. I've built network software, database software, user-facing software, backends, distributed systems, games, business engines, application servers, and more. I've lead teams and followed leaders (great and otherwise).

I'm also deeply interested and involved in environmental protection, clean food, and how agricultural systems impact human health. I live and work on a small farm with my family building first-hand experience with as many of the related systems as I can. You can read more about that side of my life on my other blog.

Supporting Open Source

I'm a prolific contributor to free and open source software projects, both on a volunteer and paid basis. I greatly appreciate donations to support the volunteer efforts. Feel free to let me know which software you're interested: it's always great to hear from users and a downside of a lot of this work is not getting to hear from the people who use the result very much.