I am creating a LibGDX based game and load assets with the Assetmanager.
All packed with Texturepacker.
For example level 1 has 96 pics with 9.78 mb disk space usage.
Level 2 has 226 pics with 17,4 mb disk space usage, not sifficant more.
I tested the game on Sony Z2 (Andoid 6) and Samsung Galaxy s7 (Android 7)
Now level 1 use on both devices ca. 140 mb RAM.
And level 2 use on s7 ca 90 mb and on Z2 600 mb.
How can it be that the older Phone use so much more RAM.
The GC should be the same or not?
Has anyone an idea?
Thank´s for helping.
By the way,: Know everyone why the assets on drive use just 10 mb and ingame 120 mb?
Would be nice to know
I would not expect the GC on two different Android versions to behave identically. Nor on two different phones, even with the same version of Android.
Regarding your second question, image assets that you have saved as PNG or JPG are compressed, but OpenGL loads them uncompressed, so they take up a lot more RAM than the source files. A typical color image takes up four bytes of RAM per pixel, regardless of the source image size.
If you are really using too much RAM, you can look at using ETC1 compressed images, which stay compressed even after they are loaded. The downside besides the image degradation is that it doesn't work for images with any alpha transparency. Instructions are here in the LibGDX wiki.
Related
The login view in our app uses large background images. To try and save on memory/app size I resized and compressed these images, which reduced their filesize significantly (less than 1mb, down from several mb).
When monitoring my apps memory usage (XCode debugger) there is a clear spike when a modified image is displayed (around 30-40mb). I'd accepted this as normal and simply made sure to release the image asap to limit memory usage.
I've recently started replacing a couple of the images and wanted to preview the new ones before resizing/compressing them. I noticed that these images (one of which is 11mb on disk and 4640x3472 pixels) has no visible effect on app memory usage whatsoever, increasing 'Other Processes' instead (by around 20-30mb).
Can anyone explain what's happening here? I want to confirm it is advisable to continue resizing/compressing the images.
Note that I'm loading the images using UIImage(contentsOfFile:) and I resized/compressed the images using GIMP. The new images have been taken straight from Flickr and unmodified.
Cheers.
The in-memory size of the image (as a UIImage) is different to the compressed on-disk size (your JPEG)
The UIImage takes 4 bytes (RGBA) per pixel x height x with - so for a 4640 x 3472 image, you're looking at 64,440,320 bytes - quite different to the 11MB on disk
I have an app, that is made with unity 2d. Exporting it to android it weighs 100MB. Exporting it to iOS weighs 1.2GB (ipa is 104MB), but inside iTunes weighs 1.2GB, which is too much.
We tried to reduce the texture size, but then, images get very pixelated on the device.
Any ideas on how to fix this?
Here is what the .ipa uncompressed shows what is getting all the MB:
sharedassets4.assets (just that file, gets 342 MB)
iTunes shows the installation size, so if you unzip your ipa file, you will get those 1.2GB. The install size on Android could also that big. Did you check that?
Usually this happens when you compressed your texture in True Color or 16 bits and the zip compression works really well i.e. on textures that have a lot of pixels with the same colors.
Possible Solutions
1) if your textures don’t require transparency, you could switch to compressed Textures (PVRTC on iOS and ETC on Android). But if the require transparency, you should not switch to compressed because transparent PVRTC can look very ugly and ETC does not support alpha.
2) I don’t know if it is possible in your project, but you could try to reduce the amount of texture by using tint or slicing them.
UPDATE 1
I currently having a similar situation and as it turns out.
--------------------------------------------
| Platform Android iOS |
|--------------------------------------------|
| APK/IPA 380MB 400 MB |
| unzipped APK/IPA 1.19 GB 1.13 GB |
| install size on device 380MB 1.15 GB |
--------------------------------------------
The difference is that iOS unzips the IPA file completely on installation and
Android contrary reads during runtime directly out of the APK, so you could argue, that is not really installed, but it is definitely another installation type.
Check your texture import options. You may have different options set for Android import and iOS import.
iOS import is usually PVRTC, which prefers textures which are a power of two in size and square (256x256, 512x512, etc).
It sounds to me like you might have iOS set to a non-compressed format.
Did you compress your meshes? Also strip bit code. Another thing I found helpful is flattening your textures, and removing layers. Also changing the indexed color count to a lower amount. For 1024x1024 it can get to 170KB, if you tweak it right.
Also remove normal maps, and change your shaders. It won't look as granular, but it'll reduce the size. You may want to offload the textures to an Assets Server, too and get textures at runtime as opposed to preloading them in your bundled assets.
As title states and as searching on google can give, on iOS there is a limit for what the devices can handle for jpeg images.
As per Apple docs (Know iOS Resource Limits):
Because of the memory available on iOS, there are limits on the number
of resources it can process:
The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels
for devices with less than 256 MB RAM and 5 megapixels for devices
with greater or equal than 256 MB RAM. That is, ensure that width *
height ≤ 3 * 1024 * 1024 for devices with less than 256 MB RAM. Note
that the decoded size is far larger than the encoded size of an image.
The maximum decoded image size for JPEG is 32MP megapixels using
subsampling. JPEG images can be up to 32 megapixels due to
subsampling, which allows JPEG images to decode to a size that has one
sixteenth the number of pixels. JPEG images larger than 2 megapixels
are subsampled—that is, decoded to a reduced size. JPEG subsampling
allows the user to view images from the latest digital cameras.
I added the enfasis on the point that's bugging me mostly. I'm trying to display a fairly big image, but still largely in the above 32MP mentioned limit, specifically its a 3995px * 2138px for a total of 8.5MP and 396kb weight (jpeg quality/compression set to 25 via PS).
Still whenever I call for that image as ex. source of an <img> tag, nothing is displayed on any iOS device I've been able to test, on emulators and couple real devices (iphone4, ipad2, 3, mini...).
Is there anything I'am missing blatantly or maybe I've not understand from the docs above?
What can I do apart replace it with a reduced file size? If forced to replace it, what is the highest width I can reach without breaking? How can I ensure iOS honor the 32MP limit mentioned?
I'm speaking in a website perspective, not a native app on the device.
It doesn't fix your current problem but if you look at image handling in IOS8 there are no longer any image size limits (CoreImage can automatically tile) - perhaps you could target that?
You can split up images and tile them.I routinely display images 180,000 x 120,000 pixels on IOS devices by chopping them up and using a CATiledLayer.
I'm using twaindotnet to scan an image with 2400 DPI. Whenever I scan a full page in color I get a message that there is not enough memory to perform this action. I tried it on a different computer with around 4 GB of ram and got the same error message.
If I scan the image as black and white or gray-scale I don't get any error and everything is working fine.
Is that a problem that is related to the scanner driver (Canon 9000F) or is this a general TWAIN problem?
gray-scale images have a bit depth varying from 2 to 8. for an image of legal size and of 2400 dpi, the size can be 163 MB ~ 654 MB.
color images have higher bit depth. take 32 for example, the image of the same size and dpi can be around 2.62 GB. plus the memory occupied by other applications, 4 GB memory likely runs out.
File Size = (height x width x bit depth x dpi2) / 8
dpi2 means dpi square
Looks like that Twain library is scanning to memory, the Twain specification also has a file transfer mode which is generally used for very large images (ICAP_XFERMECH). Twaindotnet may allow you to choose the file transfer mode when scanning.
Currently I am writing an iPad app. I am using a lot of images in this app around 40 MB of images!
This app works fine in simulator but crashing on device. I think the problem is with memory.
I wanted to know how much memory I can use on iPad?
Thanks
Saurabh
Remember that 40MB of image files on disk is far more when put in memory. On disk they are compressed but once you load it into memory you use just as much memory as a uncompressed image. If I remember right its (width x height x (bits per pixel/8)) = mem usage so for a full screen image (1024x768x(16/8)) = 1,572,864 so around 1.5 MB of RAM while on disk it may only be a couple hundred KB.
The iPad has 256 MB of memory, and of which, only around 100 to 120 are usable in an application. Note that this number is variable as the VM releases memory from previous applications, and could be less if you're using apps like iPod in the background.
My suggestion, look at what you can do to reduce the size of your images, through different resolutions, lower quality images, or such.