I hope that didn't sound argumentative. I think this topic needs more discussion and input.
Thanks again Mark for the input on this. Tom -- Tom McGrath III http://lazyriver.on-rev.com mcgra...@mac.com On Jun 5, 2013, at 8:41 AM, Thomas McGrath III <mcgra...@mac.com> wrote: > 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 _______________________________________________ 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
