5

I'm looking to create a background image for a viewgroup in an Android app, and I'm not sure what is best to do with the asset.

Is it easier (read:looks better on most phones) to simply supply the asset as 900x570 or there abouts and let Android scale it up and down automatically, or scale it myself in Photoshop and provide these images in the 3 drawable-ldpi, drawable-mdpi, and drawable-hdpi folders?

The space saving will be so small: around 10-20k, it makes more sense to me to simply let Android scale the images itself.

The targeted API will be 2.0 upwards, and tablets aren't being supported to begin with.

Chris S
  • 64,770
  • 52
  • 221
  • 239
  • Are the scaled sizes know precisely? If not they'll need to be scaled anyway and the best quality will come from starting with the largest original. – Mark Ransom Nov 01 '11 at 19:51
  • @MarkRansom I was going to use the commonest resolution sizes for each dpi, so hpi I'd stick to 854, mdpi 320x480. As far as I can tell only two phones with 2.x have ldpi screens – Chris S Nov 01 '11 at 20:09

3 Answers3

6

It is clearly easier from the developer standpoint to let Android scale the images for you, but it does not look better on most phones. Photoshop has better scaling algorithms than Android does in my experience.

kabuko
  • 36,028
  • 10
  • 80
  • 93
  • +1 for pointing out that images scaled by android might not look sharp or can be too crisp, basically sometimes it doesn't look good at all – Optimus Nov 01 '11 at 19:48
  • Right, but I must add: that is even easier for a developer to script the generation of those density-specifics images from a decent (vector if possible) master file… The UI Guidelines http://developer.android.com/guide/practices/ui_guidelines/index.html is clear for me (esp. the icons design guide that can be extrapolated) – Renaud Nov 01 '11 at 20:28
1

if you only specify one copy images in any of drawable, drawable-ldpi, drawable-mdpi, and drawable-hdpi, android will by default scale it for you

however it is a good practice put different size images for performance reasons

Optimus
  • 2,716
  • 4
  • 29
  • 49
  • I agree with Optimus, it's a best practice to provide the resized drawables… Moreover, it's just nothing to do a script to batch regenerate your drawables from sources if needed (I do that myself to convert pdf master to hdpi, ldpi, mdpi raster icons, for example)… You could use ImageMagick… It's not a matter of size but rather a matter of performance and rendering. – Renaud Nov 01 '11 at 19:46
  • This is what I meant though: it assumes your default asset is mdpi but is infact high dpi, and so the scaling doesn't blur/pixelate – Chris S Nov 01 '11 at 20:06
  • 2
    You might think that because you're only scaling down and not up, it'll always look good, but funnily enough scaling down can sometimes cause visual artifacts too and the algorithm you use can matter a lot. – kabuko Nov 01 '11 at 20:27
1

It's easier but has a cost in terms of performance.

If the target density is known, it'll be better to script all the needed conversion for your icons / splashscreen / images and forget about that to the next time your masters change… at no cost…

Here is an example using ImageMagick for my icons and listview eye-candies from pdf masters:

#!/bin/bash
convert -transparent white ic_padlock.pdf ic_padlock.png
convert -scale 36x36 ic_padlock.png ../../res/drawable-ldpi/ic_launcher_padlock.png
convert -scale 48x48 ic_padlock.png ../../res/drawable-mdpi/ic_launcher_padlock.png
convert -scale 72x72 ic_padlock.png ../../res/drawable-hdpi/ic_launcher_padlock.png
convert -scale 24x24 ic_padlock.png ../../res/drawable-ldpi/ic_listview_padlock.png
convert -scale 32x32 ic_padlock.png ../../res/drawable-mdpi/ic_listview_padlock.png
convert -scale 48x48 ic_padlock.png ../../res/drawable-hdpi/ic_listview_padlock.png
convert -transparent white ic_padlock_ok.pdf ic_padlock_ok.png
convert -scale 36x36 ic_padlock_ok.png ../../res/drawable-ldpi/ic_listview_padlock_ok.png
convert -scale 48x48 ic_padlock_ok.png ../../res/drawable-mdpi/ic_listview_padlock_ok.png
convert -scale 72x72 ic_padlock_ok.png ../../res/drawable-hdpi/ic_listview_padlock_ok.png

You can use convert with a density parameter for best rendering:

convert -density targetdensityxtargetdensity  -transparent white splash.pdf ../../res/drawable/splash.png
Renaud
  • 8,783
  • 4
  • 32
  • 40
  • I'm targeting 2.1+ devices and from these stats: http://developer.android.com/resources/dashboard/screens.html it looks like I should worry about problems with lower dpi screens when they appear.The image is also a background for an activity rather than icons, similar to remember the milk – Chris S Nov 01 '11 at 21:05
  • http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources and http://developer.android.com/guide/practices/screens_support.html may be of use. You could use convert or another density/scale-aware program. You'll just have to take care of the dp / dpi subtlety. According to the documentation "small screens are at least 426dp x 320dp". – Renaud Nov 01 '11 at 21:36