(no title)
dfinlay | 8 years ago
Taking another look at the payload showed that the otherwise innocuous launch images were 32ish Mb in size. The background of the images wasn't a solid colour. The background pattern was more of grayscale static similar to an unwatchable terrestrial TV feed. It was intended to resemble the initial sound of a CB radio used by truckers. (The "Chshhh" in "Chshhh 10-4 Good Buddy")
Since "staticy" audio/imagery like that is inherently random, each launch image(1 per device resolution) was composed of primarily uncompressable data. Switching out of the "staticy" background for a plain gray reduced the payload size to ~20M, a savings of ~30Mb. That change took approximately an hour.
The takeaway here is to take a good inventory of the payload before tackling size reduction. Otherwise you end up fighting the hard fight just to be pennywise
Also, uncompressable launch images for iPad Retina displays are stupid huge.
userbinator|8 years ago
I know this might sound somewhat obvious in retrospect, but you could've retained something similar to the original background and reduced the size significantly by generating it at runtime --- the code to create a random-looking background may only be not more than a few dozen bytes, and can be the same for multiple resolutions.
For more examples of this technique, see demoscene productions --- the following video was generated by a binary of less than 4096 bytes:
https://www.youtube.com/watch?v=jB0vBmiTr6o
Source code: https://github.com/in4k/rgba_tbc_elevated_source
Explanation: http://www.iquilezles.org/www/material/function2009/function...
richardwhiuk|8 years ago
mizaru|8 years ago
edit: I'm not entirely sure if it's possible to do something like this using launch screens.
acdx|8 years ago
itsthejb|8 years ago