I need to create and show 10 images using cocos2d. Each will be placed above previous one and all will be visible simultaneously (all of them has transparent areas). Each image has resolution 2048x1536.
When I create 5 or less CCSprites the app run fine, but when I create 6 CCSprite - it crashes on device (iPad) with error "Data Formatters temporary unavailable".
I suppose it's lack of memory, but maybe someone knows any approach for for this situation
Thanks!
A transparent image of this size uses about 12mb ram (2048*1536*4 bytes).
You are lucky that you get 5 images of this size shown before your app crashes.. which usually happens at about 50mb ram usage.
Without more knowledge about what you want to do or need to display I can't give any advice what to do .. but you won't be able to show 10 images of this size.
edit: since you are using cocos/opengl you might be able to get more images shown by changing the image format to rgb4444. This will cut the memory need to the half but you also loose much quality on your images.
Related
At present one of my quiz game require, many images of flowers based on questions asked.
I can say total 250+ images with resolution of 512x435 each.
Plus other games textures get loaded at a time.
So when game screen get opened which showing all these images, its on the spot get crashed.
I am testing this on iPhone devices. So how to handle these many textures? I was stuck in this point.
Here is overview of flowers textures.
I was displaying all these in grid view so in one scrollable screen all get displayed.
Now I hope, you understand my side point of view.
You need to reduce the amount of these images that are loaded at once, try keeping most of those images rendering components disabled using some sort of managing script when you are not seeing them, rather than simply putting them off camera and try to moderate the amount that are rendered at once. If this does not work the problem might be that the total size of the images is bigger then the amount of ram your device has. Even the IPhone X has only 3GB of ram, check if your images in total are bigger than or close to the 1GB-3GB range, unity remote 5 is probably storing these images in ram or temporary memory. It is always a good idea to try to compress your images when working with a mobile device anyway, try to put them into a texture atlas or lower the quality of them until the iphone can handle it, you should never rely on mobile devices to render tons of images at once.
Wow. That's a lot of flowers....
Okay if you need all of those textures, and you're only displaying them in the editor, I'd group them into folders.
Even if you sort the blue from the red..... etc just human readable directories it will help out a lot as you won't load ALL of your images at once.
If you are loading all of those textures at runtime, which I don't think you would as unity optimizes your built executable, I would recommend against loading all of the images at once because you will use a lot of RAM, especially if those images are 512px or larger.
With in the application you could split them into 25 at a time on the screen and you could swipe to the right to go to the next 25 or swipe back to the previous. This is how i solved a similar problem in unity a while back.
I have a 6000x3000 px image that is in a zoomable view in my xCode project. In the initial view, a button is pressed to access the view with the large, zoomable image. This all works fine, except for the time that is taken to "load" the image often times causes a crash in the app, especially when I am testing on older devices (it seems to work fine most of the time on my 4G itouch). Is there any way to "pre-render" this one large image, or anything else that I can do to prevent crashing?
Do the math: 6000 x 3000 x 3 (red green blue) = 54,000,000 bytes = 51.5MiB of raw data. The normal image handling has a lot of overhead and that simply takes too much memory.
According to this question the solution is to use a CATiledLayer. As far as I have understood it, you need to divide your large image into smaller parts and draw these smaller parts with the help of CATiledLayer.
Edit: Here's a quote from the UIView class reference:
Note: In iOS 2.x, the maximum size of a UIView object is 1024 x 1024 points. In iOS 3.0 and later, views are no longer restricted to this maximum size but are still limited by the amount of memory they consume. It is in your best interests to keep view sizes as small as possible. Regardless of which version of iOS is running, you should consider tiling any content that is significantly larger than the dimensions the screen.
Read: If it's larger, use a CATiledLayer to draw smaller parts.
I have about 20-ish high quality images (~3840x5800 px) that I need to load in a simple gallery type app. The user clicks a button and the next image is loaded into the UIImageView.
I currently use [UIImage imageWithContentsOfFile:] which takes about 6 seconds to load each image in the simulator :(
if I use [UIImage imageNamed:] it takes even longer to load but caches the images which means its quicker if the user wishes to see the same images again. But it may cause memory problems later with all that caching crashing my app.
I want to know whats the best practice for loading these? I'm experimenting with reducing image file size as much as is possible but I really need them to be high quality image for the purpose of the app (zoomable, etc.).
Thanks for any advice
[EDIT]
Hey again guys,
Thanks for all ye're advice. The project's spec's have changed a little. Now as well as displaying the images they firstly have to be zoomed in to a particular spot and when the user taps next it zooms out and then displays the next image. So I'm not sure if the proposed solutions fits?
Apple's docs recommend against trying to load single images that are larger than 1024x1024. You should look into using CATiledLayer instead, to load pieces of the images as needed.
You can have a look at this Apple sample:
http://developer.apple.com/library/ios/#samplecode/PhotoScroller/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010080
It shows how to load big images, breaking them in tiles for different zoom levels.
You can't see all those pixels at any given time, so there is no need to load them all. Load lower-res copies ("big-thumbnails") to view the complete image, then selected sub-tiles, maybe of 2 or more different resolution sets, after the user zooms in.
The CATiledLayer API may be able to handle some of the latter for you.
I'm seeing my app being killed by iOS with an out of memory message, however, while tracing the progress of the app in the Allocations Instrument, I see lots of mallocs that seem to be occurring outside of the code I've written.
I'm not seeing any leaks being caught, so I assume these allocations are supposed to be there. Thing is, because I'm not sure about why they have been allocated, I'm not sure what I can do to optimize the app and prevent the OS from jettisoning my app.
Does anyone know why the memory is being allocated, or is there any way for me to find out?
Here are a couple of shots from Instruments showing the mallocs. In the second shot, all of the allocations have the same stack trace.
EDIT
I' displaying a single large image as the UIView background (1024x768), then overlaying a smaller (600px square) UIView with some custom drawing and a third UIView (550px square) over the top of those that contains two 550px square images overlayed.
I'm guessing that this is not appropriate, and there is probably a better way of achieving the composition of views I need for the app to work.
Should this be possible on the iPad?
I think there's not really much information to go on here - if you add a bit more information about what this view in your app is doing you might get some more informed suggestions.
From the screenshot, it would appears large blocks are being allocated to display an image.
Given that I'd hazard a guess that either you're trying to display some very large images, or you UIView is large, or you have more UIViews in memory that you need to display the current screen.
I guess the easiest way to track down exactly where they're coming from would be to disable the part of the application you suspect then run again and see if the allocations still occur.
EDIT
Are all the images the same size as you're displaying them? (ie. are you trying to display a 5M photo as the 1024x768 background?) If not you probably need to scale them down to the size you are display them, or at least closer.
If you're not needing transparency, make sure to make all the views opaque.
I figured out the source of the problem - I was using
[UIImage imageNamed:#'Someimage']
to load in my images. This, as I'm sure many people are aware, caches the image data. I had enough images of sufficient size to cause my app to be jettisoned.
The problem was apparent not because of the size of the image but because of both the size and number of images I was using. The lesson here is be careful with [UIImage imageNamed:].
Thanks for all of the help, chaps!
Mallocs can occur inside of other API's that your app calls (such as loading images, views, playing long sounds, etc.) You can try changing the size of your images, views, sounds and other objects by various amounts as a test, and see if the size of the malloc'd memory changes track one of the changes that you've made.
My application contains more than 200 images each with size approx. 15 KB. I want to flip these image one by one. Is there will be any time lag for loading images? Is there any alternate method for doing that?
Anyone please help!
My application contains more than 200 images each with size approx. 15 KB. I want to flip these image one by one.
OK.
Is there will be any time lag for loading images?
Maybe. Try it and see. If there is, run your app under Instruments to see what really caused it.
Is there any alternate method for doing that?
You haven't proposed a primary method to be alternate to.
The main thing is that, since this is an iPhone app, you're probably not going to need 200 images loaded at once. Consider the Home screen: Those icons are about as small as is practical, and there are only 20 (24 on the iPad) of them on the screen at one time.
Assuming you want to allow scrolling or paging through the list, you'll probably want to keep a pageful up and a pageful down already loaded and flipped and ready to display, to make scrolling/paging faster. That's still only 60–72 images, and you can do half to two-thirds of them after displaying the visible 20–36.
Moreover, are the images always flipped? If so, then flip them at build time and copy the flipped images into your app, and do no flips at runtime. Then you're just displaying images.