
Using WebP to Reduce Native iOS App Size - barredo
http://www.ioncannon.net/programming/1483/using-webp-to-reduce-native-ios-app-size/
======
drewcrawford
The thumbnail of the eggshell (but not the blowup) was quite pixelated for me.
Chrome 16, OS X.

[http://www.ioncannon.net/wp-
content/uploads/2011/06/test2-30...](http://www.ioncannon.net/wp-
content/uploads/2011/06/test2-300x199.webp) (actual thumbnail)

[http://dl.dropbox.com/u/59605/Screen%20Shot%202012-02-04%20a...](http://dl.dropbox.com/u/59605/Screen%20Shot%202012-02-04%20at%206.17.22%20PM.png)
(how it rendered in Chrome)

Is it Chrome-related or did the OP compress with bad settings?

As for the TestWebP iOS lib itself, it takes 25 LOC to load an image, which
takes 1 LOC with system libraries. Somebody needs to go in and put a category
on UIImage to do the heavy lifting.

I just ran a grep across about 15 iOS apps I develop and the average size of
art assets is about 1MB. So this is a neat hack, and I am sure there are apps
out there with 300MB in art assets that could benefit from it. But for the
typical app, not worth the effort.

------
Zev
Neat. I don't know if I'd ever use this, but, its a cool hack.

Random thoughts off the top of my head, re: making it faster:

\- Can you can decode into an ARGB buffer, instead of an RGBA buffer? iOS uses
ARGB as its native bitmap format, so, there will probably be a bit of a speed
bump if you can avoid shuffling bits around as much.

\- I wonder if using CGDataProviderCreateWithCFData() and passing in a data
blob created with CFDataCreateWithBytesNoCopy() to see if any copying bytes
around can be reduced.

\- Maybe cache CGColorSpaceCreateDeviceRGB() somewhere (either just make it
static, or in NSThread's threadDictionary). Release on memory warnings and
such.

\- UIImage does a bunch of caching internally. You could mimic it and cache
images that have been created, to make it really cheap to re-query for an
image/reuse an already-existing image. Again, release on memory warnings and
such.

------
drivebyacct2
Could this sort of technique also be done for shrinking caches sizes of apps
that are photo-download intensive? I don't know if the size tradeoff is worth
the performance hit to reencode files as they're downloaded and cached.

