Hi Tom, No need to test JPEGs again on iOS/Android - the JPEG format itself doesn't support transparency! :)
If you need transparency then there is another option which is to store the image and it's mask (effectively alpha channel) separately, although I've not worked with these features in LiveCode. If you have a number of very large images such that your app is genuinely hundreds of megabytes it's worth doing some optimisation - some users will not download really big apps to avoid using up limited storage space on their device. From a performance perspective any further compression of the data (e.g. JPEGs are smaller) actually makes more work for the device decompressing it although you're unlikely to notice the difference - it's only when you're downloading the images that making them smaller improves performance. One uncompressed image at iPad retina resolution is at least 12MB. 14 of those is 168MB. I generalised on "large images" before - PNGs can be very good for compressing images with relatively few colours in large blocks but terrible for compressing photographs. That said, sticking with PNG there are ways to get the exact same image much smaller with a better compressor. Take a look at this: http://imageoptim.com/ipad.html On the engine forum Mark Waddingham has said that they can tweak the build process to remove images (and even the main stack) from the executable fairly easily for future releases. Then the executable will only be about the size of the compiled engine, even if the app itself is much bigger. Mark's response also hinted that maybe if you're building a universal binary (i.e. more than just armv7) you might be getting 2 copies of everything in the main stack within the executable. >> So I'm not sure what would constitute a stack being 'much larger' than it >> needs to be - in my first case it was the main stack that was large and now >> it is the images folder that is large - either way the download is going to >> be the same size and be too big for cellular download (which is why I >> believe Apple has that warning in the first place.) Well, for a photograph, a PNG might give you 4:1 compression while due to the "retina" nature of the iPad display you typically can't see the reduced quality for the same image at medium quality 40:1 JPEG compression - full resolution with more compression usually looks better than 25% (original iPad) resolution with less compression. I'd say 10x the size is "much bigger". :) The size restriction is new and unrelated to the 3G download limit (which is 50MB). For now we can only speculate what the limit is for. Mark ________________________________ From: Thomas McGrath III <mcgra...@mac.com> To: How to use LiveCode <use-livecode@lists.runrev.com> Sent: Wednesday, 5 June 2013, 13:41 Subject: Re: First App rejected for odd reasons Mark, At first I wanted to object to the need for JPEG only for large images as all of the research that I have done (especially concerning transparency issues) has told me to never use JPEG (except for the web) in most of my apps but then I realized that I have not tested those same results for iOS and Android engines, so I will need to do those tests again to verify/reject my findings. That said, using 2048 png's with transparency layers on fourteen cards with special visual effects and playing song files on one channel and a voice over on another channel did not slow down either the logic code or the effects code. I created a Ken Burns effect in LC and it runs as smoothly with the larger images as it does with smaller variations. So I'm not sure what would constitute a stack being 'much larger' than it needs to be - in my first case it was the main stack that was large and now it is the images folder that is large - either way the download is going to be the same size and be too big for cellular download (which is why I believe Apple has that warning in the first place.) I would not think that 14 retina sized images on 14 different cards is too large for a mobile app and that instead they must be referenced and that that would be a requirement. Normally I think if it was like 50 images it should be referenced but not just 14. Most LC projects I have seen all use lower quality images or regular 1024 images enlarged for retina via code, but they are definitely not retina images. All of that said, I think what you stated is spot on and should be included in a best practices type document somewhere for mobile development. Maybe with some recommendations for audio and compression comparisons. Thanks, Tom -- Tom McGrath III http://lazyriver.on-rev.com mcgra...@mac.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
