This is the typical area of supporting multiple screen sizes for android. Basically, in my cards game it was really too much to provide the setof 52 cards duplicated for the 3 folders (ld, md, hd). The reasion is the increased app size by quite a bit.
So I was wondering, if I only provide high density folder then would the device scale down the images to appropriate densities. I mean if all what I was doing before was resizing the images down then the scaling down by the device would be same. right?
If I do that (porviding only high density folder), will the image end up taking the same physical size on low density screen (I am using high density as it is generally to scal down than up).
Thank you
PS: Please don't give me the android website. I want your answer/experience
The answer is, it will scale them down for you, but the resulting images will be lower in quality than those provided at the correct density, depending on how it is downscaled and by what percentage. It may or may not be that noticeable depending on the type of graphics, but fine lines and single-pixel details will be most noticeably different.
I have a game card too and i have put all my high-res cards in res.raw.
It should be the same in drawable-nodpi.
On all the device tested, the cards render very good. The phone just scale the cards up or down depending on the screen size.
Related
Various web graphics I've created are blurred on high resolution smart phone screens, unlike desktops screens.
Do I need to:
double the image size and programmatically resize it to half
increase the resolution (e.g. 72 to 300).
My understanding is that the latter only affects print rather than digital screens.
Are others experiencing this issue and if so, what it is the recommended work-around?
Your assumptions are correct. You need to double the image size, maybe even a little more if you wanted to get picky as some screen resolutions have 3x or more pixel density than a desktop monitor. Double works pretty well though so I would start there.
Resolution, as in DPI, won't do anything for web graphics on screens besides make the image resource's filesize larger than it needs to be. You could have a resolution of 5 DPI and they would look the same as 300 DPI on a screen. The main issue with lowering DPI for web graphics is when a user wants to print your page, then any images with really low DPI would be very pixelated.
Depending on the graphics you've created you have some options besides your standard image formats. You can use SVG or create your own icon font. Both are vector images so they will look sharp on any device that supports them. Icon fonts are widely supported and SVG is decent but might need a small shim depending on what you need to do.
Double image size.
You should even render image (simple or doubled), depending on the device/viewport resolution.
increasing resolution is quite a complicated matter. Print/digital/dpi/ppi; it could work on a bunch of devices but not all.
I don't get why it's recommended to have a drawable (image) for all densities (ldpi, ..., xxhdpi).
Would it not be better to add one file with the highest needed density (xxxhdpi) and than programmatically scale that image down (e.g. for tab icons I could just set a explicit dp size)?
Therefore I would only have to manage one file and the APK file size would be smaller. I think the performance disadvantage should not be significant.
Update 1:
To be more specific: I never noticed any quality loss when using a high density image (PNG file) which was scaled down to a explicit dp value on my mdpi device.
So I was considering if the disadvantages of managing multiple image files as a coder without a designer (and the higher APK file size) might outweigh the advantages. Especially if I'm going to target newer devices (API >= 17).
Update 2:
In my case I'm more a coder than a designer. In the microphone example image of #mes I could just use a high density version of the left microphone and scale it down with no significant disadvantages?
There's no significant advantage, when designer or you simply reduce image size and put inside the ldpi, actual meaning is to paint another image for small size, because there are many cases, when simply reducing an image size produces inacurate and low quality image, and a good designer will draw another image, with few details in it, this is an example, only in this case worth to put different images in different folders
Therefore I would only have to manage one file and the APK file size would be smaller. I think the performance disadvantage should not be significant.
Yes, you are right, there no significant performance improvements, and also apk size is increases, that's why not worth to downscale the same image.
There are two reasons for this:
Typically, devices with lower density screens also tend to have less powerful hardware for image & graphics processing, along with lower memory.
Its not just the density, it is also the file size and image dimensions that are scaled accordingly.
The Android way of having different drawables for different screen form factors is thus appropriate from a technical standpoint.
First advantage is what mes mentioned: different images for different sizes.
Second advantage is memory/code efficiency: a 1000x1000 pixels image on android will take 1000x1000x4 ~= 3.8 mb of memory which is really wasted on smaller screens which can have 16mb available memory per app. You could try loading the bitmaps efficiently but that's a lot of code to put/maintain for each image and also will have performance issues on some cases.
Hi Guys And Ladies and the Others,
I develop a project. It have a lot of images. And it just run on 4.0 and above device. So If I resize all of images to xxhdpi, xhdpi blabla, the size of application became very huge. If Am I just create 72x72 (hdpi size), is it just enough ? Or do you suggest anything else ?
Thanks a lot for the answer..
The proper way to do it is to have different bitmaps for each density. This is because high density images are ideally not just high resolution copies: they're custom designed with more detail in. Also, low density devices tend to be underpowered, and so have a hard time scaling down high resolution images.
It does depend on your application and your needs, though. You might find that your application runs at a decent speed, and looks OK, with just one image of each type.
Something else you should consider is whether you can use vector graphics for some of it, or a ninepatch, which will scale automatically.
Lower quality images end up getting stretched on higher resolution screens, which can look pixelated. If you need to cut down on images, there are a number of approaches that I would suggest:
Consider the format. If you need a rasterized image, does it need to be a PNG rather than a compressed JPEG image, for example? Can you get away with using an SVG (which would allow you to support all sizes and resolutions using a single image asset)?
For rasterized images, consider whether you can tune the compression ratio.
Try supporting the highest resolution, and then skip a few resolutions in between and provide some lower resolution images for lower resolutions where details appear lossy or where you seem to be getting a performance hit from downscaling the high resolution image (that is, xxhdpi will probably be fine on xhdpi and hdpi, but then you will likely want to provide separate mdpi and ldpi images).
i am NOT an android developer and im trying to understand what they need in terms of graphical resources to make an app that functions across many android devices.
i have (tried to) read this page http://developer.android.com/guide/practices/screens_support.html , but find it somewhat bewildering. they talk as if screen density is the important thing "Supply alternative bitmap drawables for different screen densities" but then, if you dont know the size of the screen, you cant really think in terms of layout. is the idea to make buttons and logos that are the same size on all screens with the same density, such that on a large screen there is just a bunch of space, and on the small screen its all packed in tight? i dont understand how just thinking in pixel density gets me any closer to knowing what to provide.
are you supposed to create resources for every screen size AND pixel density? say it aint so.
anyway can somebody tell me... if you were developing an app what do you need for graphics? is it possible to provide graphics that are large and just let them scale down? is it inevitable that the devloper will have to mess with the graphics himself anyway? or can he be provided with sets of png files of certain sizes that will be ready to use?
thanks!
Here's what we do at my work place. Suppose we get a desing for the app. We make our designer create 3 psds versions for the same desing. the 3 psd's are for the 3 ranges of desnity. The size used for the psd are
240*320 (Low Density)
320*480 (Medium Density)
480*800 (High Density)
Most of the time when I write layouts, I use wrap_content which means a view must take the size of the content it wraps. Which works most of the time as I have a density specific version of the design so the image i use as background should be suitable. The thing to note is that, in android you can can put the 3 sizes of the same image in different folders such as drawable/ldpi, drawable/hdpi.
Eg: you have a bg.png and have a version for large phones and a version for small phones. You put the big bg.png into hdpi folder and the small png in the ldpi folder. Android will automatically select the appropriate image based on the phone density. But you need to make sure the file name is the same.
There are cases where you need to resize you background images without makeing the image looking too scaled. For this android uses the draw9patch tool. With this tool you can specify areas which can scale and areas that shouldn't scale.
9 Patch png's are your friend. Read up on them here:
http://developer.android.com/guide/topics/resources/drawable-resource.html#NinePatch
and here:
http://developer.android.com/guide/developing/tools/draw9patch.html
Those are your best bet for any kind of graphic that will stretch nicely (i.e. not gradients, they will come out slightly pixelated on some screens probably) The power of these types of images is that you can tell the system which pixels to repeat if it needs to stretch the graphic. This means that stretching can be done without loss of image quality (again depending on your image and how you choose to make the nine patch. The "show bad patches" button in the draw9patch program will show you potential problems. Hint: keep your repeatable pixels down to 1 on left and 1 on top and you'll have no problems with bad patches) Any graphics that can be made in to 9 patches will only need 1 size since the system can effectively make it whatever size it needs.
are you supposed to create resources for every screen size AND pixel density?
You may if you like. This would ensure that the application will look great across all devices. I understand that this is not feasible for all projects though. In general if you make separate resources for the different densities you'll get something that looks acceptable on most of the devices out there. All of the devices are classified as ldpi, mdpi, or hdpi (there may be an "extra high" level now too, I am not certain off the top of my head) So if you supply graphics for those 3 densities then the system will know where the device falls under and will pull the correct graphics.
is it possible to provide graphics that are large and just let them scale down?
Yes the system will scale down your graphics if needbe. But be aware there are consequences with this approach. First every time the system hast to scale a graphic up or down it is going to taking up CPU and memory to do so. This may not be an issue if you have relatively few things to scale, but if you have many it could cause noticeable lag time during on the lower power phones. Second, To my knowledge all of the graphics in android are raster, which means if you are letting the system scale something up or down image quality is going to decrease some. Again depending on the specific images this may be more or less noticeable on the actually device at runtime.
My best advice is supply them with resources of a few different sizes and run the app on as many different devices as you can. Once you see how your different resources look on the devices of different sizes you'll have a much better feel for which ones you need to supply to get the UI looking as consistent as possible across the largest swath of screen sizes and densities.
I'm writing an application where I will need a number of full screen bitmap backgrounds. Based on my naive reading of Supporting Multiple Screens in the Android documentation, to cover all my bases I should probably have 16 versions of each bitmap: all pairs of [ small, normal, large, xlarge ] and [ ldpi, mdpi, hdpi, xhdpi ]. This should reduce the work the CPU has to do for scaling the images, but will come at great storage cost.
However, this seems wildly inefficient for two reasons:
Not all of these combinations are found in practice.
As I'm just rendering vector art for each physical size (without respect for DPI), pairs like large/mdpi and normal/hdpi (which are both ~ 480x854 pixels) are duplicate files.
So, should I just provide really large images and let the system scale them down? Bite the bullet and provide a lot of duplicate images? Avoid the issue altogether and cobble some code solution with raw resources? Any other ideas? Thanks.
EDIT: Apparently you can create XML bitmap drawables which alias an actual bitmap. That solves the second inefficiency argument. Still, I wonder, what combinations of these do others provide in practice?
You would only provide images at different resolutions if you want that piece of art to be a constant size, regardless of the screen dpi it is displayed on. An icon or a button would be an example of this.
For the background images described here, you don't care what the image dpi is -- you only care what the x * y dimensions are. So you don't have to produce the cross-product of sizes vs. dpi. You only need consider the 4 screen size categories.
And within the 4 screen size categories, you only need store one of the larger sizes (xlarge or large) and let the framework scale that up or down as needed. You can also do the scaling programmatically, to ensure that you don't change the aspect ratio of your background, and you don't crop it.
See also Android game working on all screen sizes which will hopefully attract a better answer.
I would advise providing images for ldpi, mdpi, hdpi and optionally xhdpi (depending on your target users). That will allow you to cover the most commonly used resolutions just fine.
If you end up with the feeling that your application is getting too large (either by deciding to add all possible image sizes or other reasons), you can also look into allowing your application to be moved to an SD card. That way, storage won't be much of an issue anymore. (http://developer.android.com/guide/appendix/install-location.html)