I love the execution of this app, but I disagree with the underlying idea for most cases.
Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round.
Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loading a stretchable PNG. Almost all of Apple's UI system imagery is bitmap based, and for a good reason.
Not sure I can agree with you. I think vector drawing can be better in both size and drawing speed.
It depends a lot on the representation. Bitmap will not get a lot better than what we've got at the moment with JPeg or Gif. Vector representations can vary wildly in compactness and rendering speed. Eg. SVG bad, CSS gradients good. SVG bad, EPS/PDF good.
Obviously drawing from CPU can be much quicker than reading from disk. And if you draw into the GPU buffer first you get all of the advantages of GPU acceleration later.
And it can be much more bandwidth efficient.
Take streaming a bitmap over http. You have to take the penalty of the PNG header, the penalty of assembling a data:url and a 33% fixed penalty for Base64 encoding the binary bits.
So to stream a 1x256px gradient sprite there is a shedload of wasted bits.
If you're in vector land you can just send the gradient endpoints.
If you're not in WebKit land or with pre-sent vector algorithms (rare) you also have to stream the vector drawing code. In that case you can ammortize the cost of the drawing code with a simpler/smaller wire representation.
Using something like the Apple-provided CGLayer, you can draw the image once, then use it like a bitmap while it is in memory, AND they can keep it cached on the graphics card. These guys could easily produce code that does that.
In practice, CGLayer is not some pixie dust that magically makes your drawing fast. It helps only in a specific instance: when you are drawing repeated instances of the same content, into the same context. Otherwise, it ends up being extra complication for no benefit.
(Note that CGLayer is not related to CALayer or CGTransparencyLayer -- they are absolutely separate things. CALayers are incredibly useful in practice; CGLayer was kind of a dead end.)
What about localization? That combined with what others have mentioned below adds up to a lot of imagery.
There's also no reason you can't build your images the first time they're used, and save them out to PNG files for successive uses (if profiling determines that it is indeed more optimal). Even if you end up using graphics at runtime, you'll save work by using code to generate your graphics.
For instance, simply write utility programs to generate all of your graphics with code -- this is definitely faster than photoshop when you have buttons in lots of different languages. It's also useful if you want to use a font where it's not legal to embed it. (You can generate all of your button imagery using code and localization files, then remove the embedded fonts and use the generated PNG files in the release version.)
"While some of the apps have received additional features, it seems likely that the increase in size is mainly down to the huge graphics needed to fill the new iPad's 2048 x 1536 Retina Display. It's worth remembering that these are only download sizes, and once installed the apps may be even larger. Regular apps will likely receive a similar bump in size once developers update them with hi-def graphics"
I just don't understand how they could possibly be five times larger. There are 4x as many pixels, so by straight pixel count it could be 4x larger.
However, current PNG compressors are really good at optimizing flat color areas, gradients, and lines. It seems to me like most images would get only a relatively small increase in size due to this upsizing (1.5x-2x).
iOS devices can render Infinity Blade smoothly. I don't think few shapes (probably automatically cached as a bitmap) are going to be an issue.
And I don't get why Apple bothers with CgBi PNGs, since endian swap on ARM is a single cycle instruction, and it's probably free anyway while moving the bitmap to the GPU memory.
I don't think the Core Graphics vector stuff is in any way GPU accelerated, so the Infinity Blade comparison isn't appropriate.
The SoCs in iOS devices are shared-memory systems, so system memory is GPU memory.[1] But you're right, the endian swap could easily be done in the PNG decoder.
[1] I have to admit I'm not sure it's implemented as zero-copy through to userspace, though. The normal, 20-year-old GL texture APIs can certainly only be implemented via copying, and I'm not sure if OpenGL ES has anything like mappable texture pixel buffers. It would make a lot of sense though, considering how memory-starved embedded systems are.
Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loading a stretchable PNG. Almost all of Apple's UI system imagery is bitmap based, and for a good reason.