Question

I am having a problem with HDPI screens (tested on Samsung Galaxy S2).

I have a texture map which I use in conjunction with the OES_draw_texture 1.1 extension. This works fine for MDPI screens, big and small (tested on HTC Legend and Asus Transformer tablet). The texture map is cropped correctly and the texture is displayed correctly.

However, on the Galaxy S2 (and presumably all HDPI devices), the texture map is not cropped correctly. The texture map is located in the /drawable/ directory, and the minSdkVersion is set to 4, so Screen Compatibility will not be on. If screen compatibility is turned on (by setting minSdkVersion to 3), it works correctly even on the S2 because it’s emulating an MDPI screen.

I was under the impression that if you were to access a drawable resource “a”, Android would look in the specific density folder (in this case /drawable-hdpi/) and if not found, fall back onto /drawable/ or /drawable-mdpi/. I have not been able to find documentation to support this however.

My questions are as follows:

• What is the behaviour of Android’s resource searching? Does it actually fall back onto mdpi if it cannot find the resource in hdpi? Source?
• Why is OES_draw_texture GL-ES1.1 extension failing to crop correctly? I suspect it has to do with px and dp; draw_texture typically uses direct pixels, but Android may be trying to use dp and therefore multiplies all crop positions by 1.5 since the resource is located in the /drawable/ folder?
• Is there a way to force an HDPI device to emulate MDPI without using screen compatibility?

Any knowledge into this would be appreciated.

Answer 1

From here. (When loading your texture)

// This will tell the BitmapFactory to not scale based on the device's pixel density:
// (Thanks to Matthew Marshall for this bit)
BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inScaled = false;