I am new with cocs2d. I have created an app using Cocos2d. The app is working fine but problem is that application size is too large 350MB. There are many images in this app. I have used png and where possible jpeg images. There are many png images that have larger than 1 mb.
Is there any way to reduce the application size. I've reduced the size whereever possible. Is there any other format that can be used in place of png? There are no many animations. The png are used only purpose of transparency.
Your images are way out of size. Even if you put them on server, and then download it will take time to download.
The best option is to reduce the image size. A couple of sites that can help you do that are:-
Reduce image size
Compress image size
You can keep the image content on your server and then download the image content asynchronously (which is more imp download it first). If there are levels then download initial levels first and download remaining on the background thread. You can always display a loader on launch and display some help kinda stuff meanwhile the data gets download and cached.
You can make use of SDWebImage and other libraries to get your images stuff async.
Hope it helps.
While your pictures are fairly large and you should try to reduce the number and size, you can make gains through packaging the .png into pvr.ccz files. There are multiple different programs available to do this. I like to use Texture Packer which is available here: http://www.codeandweb.com/texturepacker
You can find some tips in my post on reducing memory usage & bundle size.
Most importantly use texture atlases in .pvr.ccz format and where possible reduce image color depth to 16 bit. Avoid JPGs altogether because they're terribly slow to load in cocos2d.
There is no issue in using png files although your images are too large, You can reduce their size by 70 - 80% by using tinypng and it will not going to hurt your graphics.
https://tinypng.com/
I usually edit the image size now https://resizeimage.io , you try!
Related
Are there any web tricks to speed up the loading of a web page. I have a few pages where I have images which were created in photoshop, but they are saved as a PNG. The load time is fairly slow of the page due to this, is there anyway to speed up a page load? They are in the region of 1.2/1.5MB
Reducing the size of the file would be a significant advantage.
Additionally converting the asset to webp for Chrome and Firefox, jp2 for Safari and falling back to png would help retain quality while reducing file size.
If the image isn’t in the first viewport you can also try lazy loading the image with something like lazysizes or at the very least the loading attribute.
You could compress the images using an online tool. Although, this may slightly reduce the quality.
I’ve used this site before: https://tinypng.com/
Other than that, I’m not sure if you can “speed up” the load time for a webpage.
You can check your website images here
https://www.imghaste.com/pagespeed/
1.2 to 1.5MB for each image is way large.
You need to adopt a process where you can optimize/shrink images for your website.
If you don't really need the images to be PNG you can always convert them to JPEG.
https://www.imghaste.com/converter
I have a lot of png images in my app which is causing my app to overload the real memory usage of my iPad2 device. My whole app folder with lots of sound files and png images is only about 50-60 MB precompiled, 90 MB on device, but still I'm easily going up to 300MB++ at run time.. ViewControllers on top of former ViewControllers etc.. which I'm also trying to fix..
What I find strange is that by just displaying one background .png image I'm adding 12 MB onto real memory usage(seen in instrument). The image that I used to fill a ImageView image in the storyboard is only 700 KB in my project folder. Taking it out or leaving the image field empty saves me 12 MB of memory...
I'm using a lot of these background images as well as other foreground images in the app which is eating up way to much space.
Any suggestions or help is appreciated
Thanks.
Well, 700kb image on disk space doesn't mean 700kb image in memory. It is compressed while stored on disk, but when it is taken into memory - it will grow in size.
If you are using a lot of images in your project, I would recommend using [UIImage imageWithContentsOfFile:] method. It doesn't cache images internally and you have more control over the memory than using [UIImage imageNamed:].
For me, the general rule of thumb is this. If the image is huge and used once in the app -> [UIImage imageWithContentsOfFile:], but if the image is reused in many places over the app -> [UIImage imageNamed:].
In addition, if you have to use .png format because it has transparency, then you might try giving .webp a chance. This format is not supported officially in ios, however there is a custom implementation on github you can take a loot at.
UPDATE:
I personally don't use interface builder in my apps at all, as I find it extremely time consuming and slow. Instead I create all views programmatically, that gives me more flexibility like choosing between [UIImage imageWithContentsOfFile:] or [UIImage imageNamed:]. You can just set an Outlet to your UIImageView and then set the actual image in code.
As for pngs, there is no such thing as the preferred type of images in iOS. It really depends on your case. If you need transparency -> png, need just a plane image -> jpg. This is just a simple example.
And as for .webp, this format, as I have already mentioned, is not officially supported in iOS, but you can add your own support for it. Basically, .webp will let you replace .png and reduce the size of project folder without loosing transparency in your images.
Hope this helps, cheers!
The landing page for an ipad retina (i.e 1536 x 2048) is about 2MB. Apple seems to mandate using a PNG for landing pages. Is it possible to reduce this file size? (my landing page is really simple already)
actually the byte size of image not only depends upon the resolution but also on bit depth.
e.g. 100x100 PNG 16bit/24bit
you can reduce the bit depth of the png if you feel like it is not affecting the image quality and if you do find the image quality becomes unacceptable on reducing bit depth then your image is not that simple.
you can also use colors/gradient instead of an image so that you can completely remove the image
you can also use the tiled image (if it suits you) and can keep a small image in the resources.
see... you have lots of choices my friend..!!
I am using ImageOptim to reduce all my images. Works great and fast. Just download, open and drag and drop a folder or all your images onto the interface.
http://imageoptim.com/
There is even a case study on how well this tool can be used to shrink your iOS-Apps:
http://imageoptim.com/tweetbot.html
Use Image Optimiser. You can optimise image online.
I am writing an iOS app which need to load a lot of full-screen size images into OpenGL. Image storage space is a concern, so I am using png or jpg. Problem is: Loading the image data takes way too long (100s of ms on an iPad2).
I was wondering if someone knows the fastest way to load good-quality compressed image data on an iPad or similar? This could include switching to different image compression formats (?)
Here's what I've found:
Loading jpg via the iOS implementation of libturbo-jpeg is faster than any way I found for png.
If you split jpg images in two, you can parallel-decompress via GCD which almost cuts the load time in half. Still not enough!
The PowerVR compressed PVRTC format can be loaded very quickly, but both compression ratio and image quality are way outside what I need...
No idea how jpeg-2000 would perform, but it seems to be optimized for compression ratio rather than decoding speed.
Any ideas?? This must be a common problem for games or similar..
Are there any newer image formats (jpg is 1986!!) which have portable implementation, maybe slightly less compression than jpg, but decode much faster?
This library might help you out:
https://github.com/path/FastImageCache
I have an app that will display a bunch of images in a slideshow. Those images will be part of the bundle, thus distributed with the app.
All the images are photographs or photographic, etc.
I've read that it's preferred to use PNG as the image format, but seeing that the JPG version will be much smaller, I'd rather be using that.
Are there any guidelines which format to use and in which case?
PNG's are pixel perfect (non-lossy), and require very little extra CPU energy to display. However, large PNGs may take longer to read from storage than more compressed image formats, and thus be slower to display.
JPG's are smaller to store, but lossy (amount depends on compression level), and to display them requires a much more complicated decoding algorithm. But the typical compression and image quality is usually quite sufficient for photos.
Use JPG's for photos and for anything large, and PNG's for anything small and/or designed to be displayed "pixel perfect" (e.g. small icons) or as a part of a composited transparent overlay, etc.
Apple optimizes PNG images that are included in your iPhone app bundle. In fact, the iPhone uses a special encoding in which the color bytes are optimized for the hardware. XCode handles this special encoding for you when you build your project. So, you do see additional benefits to using PNG's on an iPhone other than their size consideration. For this reason it is definitely recommended to use PNG's for any images that appear as part of the interface (in a table view, labels, etc).
As for displaying a full screen image such as a photograph you may still reap benefits with PNG's since they are non-lossy and the visual quality should be better than a JPG not to mention resource usage with decoding the image. You may need to decrease the quality of your JPG's in order to see a real benefit in file size but then you are displaying non-optimal images.
File size is certainly a factor but there are other considerations at play as well when choosing an image format.
There is one important thing to think about with PNGs. If a PNG is included in your Xcode build it will be optimized for iOS. This is called PNG crush. If your PNG is downloaded at run time it will not be crushed. Crushed PNGs run about the same as 100% JPGs. Lower quality JPGs run better than higher quality JPGs. So from a performance standpoint from fastest to slowest it would go low quality JPG, high quality JPG, PNG Crushed, PNG.
If you need to download PNGs you should consider crushing the PNGs on the server before the download.
http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
The Cocoanetics blog published a nice iOS performance benchmark of JPGs at various quality levels, and PNGs, with and without crushing.
From his conclusion:
If you absolutely need an alpha channel or have to go with PNGs then
it is advisable to install the pngcrush tool on your web server and
have it process all your PNGs. In almost all other cases high quality
JPEGs combine smaller file sizes (i.e. faster transmission) with
faster compression and rendering.
It turns out that PNGs are great for small images that you would use
for UI elements, but they are not reasonable to use for any full
screen applications like catalogues or magazines. There you would want
to choose a compression quality between 60 and 80% depending on your
source material.
In terms of getting it all to display you will want to hang onto
UIImage instances from which you have drawn once because those have a
cached uncompressed version of the file in them. And where you don’t
the visual pause for a large image to appear on screen you will have
to force decompression for a couple of images in advance. But bear in
mind that these will take large amounts of RAM and if you are
overdoing it that might cause your app to be terminated. NSCache is a
great place to place frequently used images because this automatically
takes care of evicting the images when RAM becomes scarce.
It is unfortunate that we don’t have any way to know whether or not an
image still needs decompressing or not. Also an image might have
evicted the uncompressed version without informing us as to this
effect. That might be a good Radar to raise at Apple’s bug reporting
site. But fortunately accessing the image as shown above takes no time
if the image is already decompressed. So you could just do that not
only “just in time” but also “just in case”.
Just thought I'd share a bit of decompression performance data...
I'm doing some prototyping of a 360 degree viewer - a carousel where the user can spin through a series of photos taken from different angles, to give the impression of being able to smoothly rotate an object.
I have loaded the image data into an array of NSData's to take file i/o out of the equation, but create NSImage's on the fly. Testing at near max frame rate (~25 fps) and watching in Instruments I see the app is clearly CPU-bound and there's an approximately 10% increase in CPU load showing ~275 kb png's vs. ~75 kb jpg's.
I can't say for sure but my guess is the CPU limit is just from general program execution and moving all the data around in memory, but that image decompression is done on the GPU. Either way and the JPG vs. PNG performance argument looks to favour JPG, especially when the smaller file sizes (and therefore smaller sizes of objects in memory at least in some parts of the chain) is taken into consideration.
Of course every situation is different, there's no substitute for testing...
I have found massive differences in animation performance when using jpegs vs png. For example placing three screen-sized jpegs side by side in a UIScrollView and scrolling horizontally on an iPhone4 results in lag and a thoroughly unpleasant jerky animation. With non-transparent pngs of the same dimensions the scrolling is smooth. I never use jpegs, even if the image is large.
I think if you want to use transparent, you have no choice except PNG. But, if your background is opaque already, then you may use JPG. That is the only difference I can see
'Use JPEG for photos' as mentioned in Human Interface Guidelines under section Produce artwork in the appropriate format.