Is there much of a penalty to be paid for "standard" PNGs on iPhone?

If I use an unoptimized PNG for my Default.png image, how much am I going to pay for that in startup performance? I realize that Xcode optimizes PNGs when they're cop开发者_如何学运维ied into the .app bundle, but I'm performing a little build-time scriptery and ending up with regular PNGs there. Seems to run fine, but I want to be sure.

I presume Xcode, among other things (see below for details), optimizes PNGs to make them as small as possible. This is probably done with a combination of two programs freely available on the internet: PNGcrush and AdvanceCOMP

Both of these programs look at a PNG file and see what the can do to make the PNG smaller; a PNG file generated differently (such as with Microsoft paint) works just fine (but see below for iPhone-specific issues) but is a little bigger. PNGs were originally created in the mid-1990s, when a top-of-the-line Pentium had a fraction of the performance of even the slowest iPhone; they will always load quite quickly (unless they are really huge images).

Google is your friend: A simple “xcode PNG optimization” Google search reveals that one person points out that iPhone’s PNG optimization affects the alpha component, so the PNG may look a little different in the final application.

Also, from that blog entry:

When you use any other file type (or if you load a non-optimized PNG files), your iPhone has to do the byte-swapping and alpha premultiplication at load-time (and possibly re-do the alpha multiplication at display time). Your application basically has to do the same processing that Xcode does, but it's doing it at run-time instead of at build-time. This is going to cost you both in terms of processor cycles and memory overhead.

So, yeah, use xcode optimization for anything end users touch, but the other build is fine for developers and SQA testers to look at.

Why not just run the same pngcrush XCode uses on the images you copy into the bundle? Sure it's not a huge performance hit, but optimizing app startup time is one of the more worthwhile things you can do.

The runtime penalty is that it swaps the byte order from RGBA to BGRA and premultiplies the alpha on all the pixels.

If it's just the Default.png you are worried about then the performance issue is not really noticeable. On the other hand, if you are loading a lot of png files, it is wise to process the files ahead of time and then allow XCode to optimize them during the copy file build phase.