I am working with images in IOS. The project has same images with 3 different resolutions - 1x, 2x and 3x. The app picks up the required version by itself, depending on the screen resolution of the phone. i have few questions regarding this.
How does the app picks up the best suitable version?
Why don't we keep the images with the highest resolutions, instead of keeping multiple version?
Does applying high resolution images to a low resolution device affects the clarity of image?
Even in android, we do the same. We have multiple versions of the same image. So, these questions applies to android as well.
We need different size images so that OS loads particular image size that is required at that time, Smaller images reduces memory usage. It leads better efficiency. If your app uses less memory, it also means more apps can occupy memory simultaneously, faster multitasking. Phones with low pixel density are usually the old phones with less memory, so that's why giving a low resolution option for those phones makes the user experience more flexible.
Related
Regarding Android's call to provide multiple versions of a bitmap/image, why can't only the highest resolution image be used?
E.g if the xxhdpi image is available - will that be able to scale down to all lower density versions or will it just mean it will scale bigger than the allocated size (View)?
PS: If I'm using a background image, does scaling matter? E.g. should I still provide multiple versions of 1 image to fit different pixel densities?
Usually image scaling operation is resourceful and the outcome might be worse than using pre-scaled image.
It has already been answered several times, but I will answer it again. Btw I'm not myself a big pro in Android, but I will try to answer in the best way possible.
Automatic scaling is a thing in Android, but using that is a waste of resource, we already know that using a PNG Graphic asset is a waste of CPU/GPU power when we can use XML for basic designs (which uses less resources), so why waste more power for downscaling it (which increases app opening time and makes it laggy), simply creating multiple sized images for different display sizes is the best option.
A simple and convenient option is to use a free software like Adobe XD which supports export into different sizes.
Simple answer: Avoid using PNG(or other image format), but when you don't have other options do create multiple sizes to save resources.
I am developing an android application , How so ever it has memory issues for Kitkat devices. How do these firms do to optimize their memory usage?
They will only load a low resolution image as a preview that fits exactly the size of the element. This is also stated on the Android Developer Page. I would suggest you to follow this training and see if it helps you.
Given that you are working with limited memory, ideally you only want to load a lower resolution version in memory. The lower resolution version should match the size of the UI component that displays it. An image with a higher resolution does not provide any visible benefit, but still takes up precious memory and incurs additional performance overhead due to additional on the fly scaling.
Im designing a game for android, I have my assets in low resolution that looks fine in small screens, if the game runs in a bigger screen it comes out pixelated, should I make different spritesheets for different resolutions or just one in HD and then reduce the images according to resolution? the second one sounds better but Im worried if all the scaling would take its toll on performance
I do use several SpriteSheets with different resolutions on LibGDX, here is why :
When you have to support devices with screen resolution ranging from 320*480 to 2560*1400 (And maybe up to 4K in a few years), it's almost impossible to have a perfect result on all these screens with an unique spritesheet resolution. If you use a virtual screen resolution (viewport), you may work on a single resolution and create assets accordingly and let this viewport automatically scale to the screen, so that your game will look the same on any device.
So, one may argue that a single HD spritesheet may be enough. However, most low-cost or old mobile devices are sometimes unable to load high resolution textures, so you may lose support for these devices if you only use HD graphics. What's more, downscaling assets programmatically often lead to poor and unpredictable graphics results in my own experience.
So personnaly, here is what i do :
I check the screen resolution and the max size of texture the device can load.
Using these values, i choose a viewport size and a spritesheet size choosing from spritesheet resolutions i pre-defined. (Low, medium or high resolution)
To help resolving assets according to the screen resolution, libgdx provide the ResolutionFileResolver class.
However, you should also read : https://gamedev.stackexchange.com/questions/24638/resolution-independence-in-libgdx
Is there any drawback in only using xxhdpi images and letting android scale the images?
(Yes it might be more cpu intensive, but is it notable?) I tested it on a samsung s2 and the difference were small.
Is there a restriction to only use this if set minSdk to XX, becaus there were no xxhdpi?
Here are a couple drawbacks I can think of:
More CPU intensive to resize the images, the app will use more battery and might feel more sluggish, especially on older devices.
The images that you are going to load will be bigger and will use more memory. On mdpi/hdpi devices, the VM in which your app run will only have a smaller amount of heap memory available, and you might run into Out Of Memory Exceptions much more frequently if you only load high quality images.
The quality of the image might not be as good on mdpi/hdpi devices, because of the resizing. This really depends on what image you are loading, but images with sharp lines might appear a little blurred. But I also want to point out that this only applies if you are really making pngs for each size from a vector graphic. If you are just resizing your xxhdpi png into smaller one, you're probably doing the exact same thing that android is doing on the fly, so there will be no difference at all.
Yes, drawable xxhdpi was introduced in API 19.
If you want to run your app in a lower API level, you wont get any image because the system can't access the xxhdpi drawables.
This is also true if you only use only xhdpi with Android 2.3.
I'm not so sure there is going to be an image quality difference: even if you do provide the different versions of the graphic, they're likely just downscales of the original anyway. I'm willing to bet the difference between doing it at run-time and design-time is not going to be significant enough for a user to notice on a mobile phone screen.
I'm also not sure about a performance difference - however, even you admit that there is likely to be a non-zero negative impact. Given that fact, I think it's worth asking "Why not provide pre-scaled graphics?" There are tools (like the Android Asset Studio Icon Generator) that bring the level of effort required to make that happen almost to 0.
In mobile, any deal where you trade nearly 0 work for any potential performance enhancement is a deal you should take.
In addition to Stephane answer I must say that an image quality would be bad especially on mdpi devices.
I've read this question but am still uncertain of the value of different DPI targets.
Doesn't supporting multiple density images add to the .apk file size, whereas just using high-res images offers a solution for all screens (using automatic scaling)? There's still only one binary for users to install unless one limits the app to phones and tablets, so the smaller the file, the better.
Is downscaling of images dependent on hardware implementation and sometimes messy nearest-neighbour resampling is used, or can I be confident it'll be a bilinear resampling no matter the hardware, which is fine for photos? And is there a significant performance gain in providing suitably presized bitmaps?
It seems to me that the extra meg or two of asset files may be more cost than gain.
I was toying with the same thing myself. Eclipse makes it easy to add every resolution as you can simply add an Android Icon Set which automatically creates the right sizes for you, it makes the app a bit bigger. Apparently XHDPI is only supported from Froyo (API 8) so if you're going to support before that you need to include HDPI. Also older devices, the rescaling doesn't look as nice and it's slower but the new devices, there's no real difference. At the Google IO I recall them saying it's okay just to use the XHDPI if you're targeting at and above API 8.