iPad 3 Image Decompression Benchmarked

From the statements made at the iPad !!! launch event we assumed that the A5X must be a beast, shattering all previous benchmarks made. There are various kinds of measurements that you can take to compare the new iPad !!! to its predecessors. For one the raw CPU power seems mostly unchanged as judged by looking at Geekbench which measures Integer, Floating Point, Memory and Stream performance.

Then there is the raw graphics performance which can be gauged with the GLBenchmark, there you see the iPad !!! shine, or at least sparkle a bit. Apple apparently optimized the hell out of that, people expect at least the same fluid frame rates on Retina when playing games as the iPad 2 had.

But when are you actually interested in raw computing power or raw OpenGL graphics power? What we are more interested in is how fast the iPad can take a file on disk, decompress it and display it on screen. We previously did a comprehensive Image Decompression Benchmark to compare all iOS devices in this regard. We now have the numbers for the new iPad, so let’s compare!

Arun Sirrpi from Australia was so kind to run our image decompression benchmark (available on GitHub) on his new iPad and recorded the numbers for us. This benchmark measures duration for 3 phases: alloc/init of the UIImage, decompression time, drawing time. This is explained in much greater detail in the previous article.

The numbers where, for iPad 2 resolution:

and for iPad !!! Retina resolution:

Based on these numbers we assumed that Apple would only launch a Retina-iPad if they can speed up image decompression by a factor of 2-4. The default loading image that is displayed when launching an app takes about 100 ms to decode and display on iPad 2. You can see that as the first bar in the “PNG Crushed” column. A Retina-sized default image would take 400 ms to display on iPad 2.

We figured, Apple would never release technology that would would feel that much slower. If they could quadruple the decompression speed so that also Retina-images can be displayed in 100 ms then – so we thought – it would feel just as fast.

4x, Yeah, Right.

Launch images are just one factor why image decompression performance is key for most modern iPad applications. Think of all the magazines and catalogues. Anything will full-page graphics is dependent of being able to decompress those and display them quickly. In an ideal world you would need less than 16 ms (60 fps) to decode and display a page. But neither the iPad 2 nor the iPad 3 are able to achieve that. Which is why we developers have to resort to all kinds of tricks (background rendering) to keep user interfaces feeling smooth.

Ok, I hope you get the picture and an idea of the methodology. Without further ado, let’s compare the actual numbers. We’ll look at 1024*768 and 2048*1536, same sizes for raw performance and Retina to non-Retina to compare the “felt performance”. We’ll compare 80% JPEGs because this is the compression factor that we found to be visually indistinguishable from uncompressed images for full frame catalog pages.

PNG Crushed, 1024*768 (init+decode+draw)

• iPad 2: 5 ms + 89 ms + 18 ms = 113 ms
• iPad 3: 1 ms + 50 ms + 18 ms = 69 ms

– 47%

JPG 80%, 1024*768 (init+decode+draw)

• iPad 2: 2 ms + 32 ms + 18 ms = 52 ms
• iPad 3: 2 ms + 32 ms + 17 ms = 51 ms

– 2%

PNG Crushed, 2048*1536 (init+decode+draw)

• iPad 2: 5 ms + 266 ms + 96 ms = 368 ms
• iPad 3: 2 ms + 171 ms + 66 ms = 238 ms

-33%

JPG 80%, 2048*1536 (init+decode+draw)

• iPad 2: 1 ms + 121 ms + 69 ms = 192 ms
• iPad 3: 1 ms + 122 ms + 66 ms = 189 ms

– 2%

So at first glance I must says that it does not look good for the 4x improvement we were hoping for. With a bit of good will we can give Apple a 2x improvement (-50%) that they claimed over the A5. But this good will breaks down when dealing with JPEGs, because it seems like not everybody at Apple got the memo. Crushed PNGs have an improved processing time of between 33% and 47%, JPEGs only 2%. If anything then that might just be from a slight improvement on SSD read times.

About “felt performance”, that is: does an app feel faster on the iPad 3?

Not so much, the initial launch image will display in 113 ms on an iPad 2, but take 238 ms on an iPad 3. If there aren’t any other optimizations – remember, the CPU performance is the same – then apps will take 125 ms longer to start on iPad 3.

The biggest problem that I foresee for iOS developers of magazines and catalogs is the “felt performance”. Even when using 80% JPEGs for the individual pages you only get 5 fps (128 ms per image) versus 19 fps (52 ms) for full screen images. This you would see as a jerk when scrolling from one page to the next if the developers are decoding and drawing the page on the main thread.

Conclusion

Now we know why the A5X is called like this. It is essentially the same CPU as an A5 with slightly improved graphics. The geek in us calculates X to be around 1.4. But only for PNGs. Or maybe JPEGs in an iOS update.

It is very possible that the part of iOS that is used for hardware-accelerating the decompression of JPEG images was somehow forgotten or was not ready for the initial iOS 5.1 version that comes pre-installed in iPad !!!, if this is the case we’d be getting a tremendous performance boost from 2% to 40% just like with PNGs. That’s a bit embarrassing to Apple, so we can assume that this won’t be discussed but rather snuck in under “various performance improvements”. #JPEGate

For us developers this should ring an urgent bell to develop techniques that can give us rich interactive magazines/catalogs without the need for full-screen images. How about packaging only the images and using a great open source framework like our DTCoreText for rendering the rich text instead? Just sayin’!

Categories: Apple