959203 - Experiment: Try using only XXHDPI resources

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Theme and Visual Design, defect)

Description

[Ian Barlow (:ibarlow)]

I was chatting with an Android developer friend of mine from a previous job, and he said that they found in their app development that using multiple resolutions for resources was pretty unnecessary, and that simply scaling XHDPI assets for HDPI and MDPI devices worked fine.

We should try this. Seems like it would be a nice little win for app file size, and also for design production peace of mind :)

Not sure how much effort this is from engineering, but I would suggest making a build with large assets only, and taking before and after screenshots for each device resolution to see how the assets hold up.

Comment 1

[Richard Newman [:rnewman]]

Looks like we have about 240KB of PNGs in non-XHDPI directories. I didn't dig any deeper into which ones were only present in non-XHDPI, and thus can't be deleted, but that's probably a ballpark figure.

Comment 2

[Richard Newman [:rnewman]]

See also Bug 1039789.

Comment 3

[Chris Kitching [:ckitching]]

Random comment: Wouldn't this increase decode time and possibly memory consumption compared to simply using smaller images?

Shouldn't this be a wontfix now the splitapk work is making decent progress?

Comment 4

[Richard Newman [:rnewman]]

(In reply to Chris Kitching [:ckitching] from comment #3)
> Random comment: Wouldn't this increase decode time and possibly memory
> consumption compared to simply using smaller images?

It'll reduce APK size, and that might be enough of a win. Shouldn't increase memory consumption if our bitmap loader is directed correctly.


> Shouldn't this be a wontfix now the splitapk work is making decent progress?

Not necessarily. Considering that relatively few devices would use the >9 APK with h/mdpi images, this might be worth doing.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

More info: http://stackoverflow.com/questions/5998865/only-use-xhdpi-drawables-in-android-app

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

and: http://stackoverflow.com/questions/14004286/android-drawables-use-xhdpi-for-hdpi

Comment 7

[Wesley Clark]

I'm interested in working on this.

Comment 8

[Richard Newman [:rnewman]]

Wesley: most of the work here will be in doing builds with various files deleted, and then testing and measuring the output on various devices.

Do you have an array of Android devices available to you? If not, this might not be the best bug to start with.

Comment 9

[Wesley Clark]

I have an HTC One, a Samsung Galaxy S3, and a Nexus 7 tablet. Are three devices enough to test and build with? If not, I'll look for something else to which I could contribute.

Comment 10

[Murtaza]

I do have a number of devices available and am experienced with emulators, since I'm an android developer. If no one's taking this, I can surely work on it.

Comment 11

[Murtaza]

I do have a number of devices available and am experienced with emulators, since I'm an android developer. If no one's taking this, I can surely work on it.

Comment 12

[Martyn Haigh (:mhaigh)]

Esentially we only need hdpi and xhdpi or xxhdpi assets - as Commonsware mentions here http://stackoverflow.com/a/19196749/264276, the system will downscale from the largest given asset.  You will, however, need to specify an hdpi asset, as neither xhdpi nor xxhdpi existed for API Level 7 and below.

The only potentially subjective bit of this task is working out whether the assets look good downscaled,  I've personally never had an issue with it.

Comment 13

[Martyn Haigh (:mhaigh)]

Murtaza, Wesley: Either of you fancy taking this on?

Comment 14

[u421692]

I would like to work on this bug if nobody is assigned.

Comment 15

[:Margaret Leibovic]

(In reply to Mihai Pop from comment #14)
> I would like to work on this bug if nobody is assigned.

Go for it!

Feel free to bug rnewman or mhaigh if you need help :)

Comment 16

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Martyn Haigh (:mhaigh) from comment #12)
> Esentially we only need hdpi and xhdpi or xxhdpi assets - as Commonsware
> mentions here http://stackoverflow.com/a/19196749/264276, the system will
> downscale from the largest given asset.  You will, however, need to specify
> an hdpi asset, as neither xhdpi nor xxhdpi existed for API Level 7 and below.

We don't support API level 7 (only >= level 9). Does this mean we only need xhdpi or xxhdpi?

Relatedly, I just want to note that I filed bug 1104366, which is for the xxxhdpi on the Nexus 6 - I'm not sure how this factors into this discussion.

Comment 17

[Richard Newman [:rnewman]]

> Does this mean we only need xhdpi or xxhdpi?

That's my understanding, yes.


Note, however, that for Gingerbread constrained builds we ship only <=hdpi, because it's a significant size saving, and we'd rather save size than have higher quality.

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/Makefile.in#357

Until we drop Gingerbread support, or decide to re-add weight to the APK, we can't avoid creating lower density assets.


We might consider using a mirror of that approach -- ship only {x,xx,xxx,xxxx}hdpi -- for 10+ builds in our aapt invocation.

It'll be a small saving (240KB of PNGs), at the cost of creating xhdpi+ assets for stuff that's currently only hdpi or mdpi.

This should be pretty easy to test: just ape that AAPT invocation in the Makefile.in, and see what breaks when you exclude hdpi/mdpi.

Comment 18

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

liuche got me digging in. We're killing GB soon – we can probably switch over to all xxhdpi assets at that point. [1] indicates this works (read the comments).

Note rnewman's comment 17 that we have to build assets for stuff that's only in hdpi (or we can ship only these hdpi assets but it could get tricky to keep track of what we actually want to keep in the hdpi folders).

[1]: http://stackoverflow.com/a/21484100

Comment 19

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

See comment 18.

Comment 20

[:Margaret Leibovic]

This sounds like it would be good to fix, but it doesn't need to track a release. We can do this as part of the general work to clean up after dropping Gingerbread support.

Comment 21

[a.bissarinova]

Hello! Is this bug still relevant? Can I work on it?

Comment 22

[Sebastian Kaspari (:sebastian; :pocmo)]

It's still relevant: We want to reduce the APK size and only shipping XXHDPI resources would be helpful for that. However currently I'm not able to mentor this.

The big question here is whether xxhdpi will be used by all supported devices (currently our minSdkLevel is 15).

Flagging antlam: With the upcoming UI refresh we might update a lot of the resources - so only using xxhdpi could be part of that refresh.

Comment 23

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.