Android window.scale returning 1

Lime
#1

Hi guys,
I’m testing a simple app I made on my Android samsung s24 and Application.window.scale is returning 1, which doesn’t seem right?

Application.window.display.dpi returns 416, which when you divide by 160 gives a scale of 2.6.

“adb shell wm density” returns 480 - which would correspond with a 3x scale - which seems more accurate?

Is this a known issue for android or am I missing something? I’d be happy to start contributing to development potentially if that would be useful.

Thanks,
Greg

#2

Do you have this in your project.xml?

<window allow-high-dpi="true"/>
#3

Hi thanks for replying so quickly! Yeah, I definitely have the allow-high-dpi flag set in my project.xml file - that was one of the first things I tried, but it doesn’t seem to make a difference, the scale returns 1 no matter what.

I’ve also noticed Hashlink it doesn’t act like I’d expect - I’m running a HL build on windows on a high resolution display which has a scaling of 1.5x. Lime is reporting the scale as 1x but is also internally scaling the window contents up (I guess behind the scenes) so that the contents of the window are kind of blurry. I guess this makes the 1x scale accurate, but also means you can’t really have properly DPI aware apps using it. We don’t use HL as a production platform so it’s not the end of the world for us, but thought it worth mentioning. It’s worth noting that running the same app on html5 target in chrome it picks up the scale as 1.5 correctly and doesn’t scale up the window contents - this is what I would expect to happen ideally.

PS. I don’t mean to sound critical or anything, Lime is an amazingly useful platform, I’d love to be able to contribute at some point once I know a bit more about it.

Thanks,
Greg

#4

I guess that window.scale isn’t necessarily supposed to be exactly the same as the dp scaling system in native Android development.

You can also do your own calculation of an appropriate scale based on the value of Capabilities.screenDPI.

Feathers UI does something like that with its ScreenDensityCalculator class.

var scaler = new ScreenDensityScaleCalculator();
scaler.addScaleForDensity(120, 0.75); // ldpi
scaler.addScaleForDensity(160, 1); // mdpi
scaler.addScaleForDensity(240, 1.5); // hdpi
scaler.addScaleForDensity(320, 2); // xhdpi
scaler.addScaleForDensity(480, 3); // xxhdpi
scaler.addScaleForDensity(640, 4); // xxxhpi
var result = scaler.getScale(Capabilities.screenDPI);

You can define any set of DPI buckets that you prefer.

Unfortunately, allow-high-dpi doesn’t work yet on Windows targets that use lime.ndll or lime.hdll yet. That includes C++, HashLink, and Neko on Windows. allow-high-dpi works with html5 on Windows, though.

This is because we use SDL, which is a C++ library, and didn’t support high DPI on Windows until somewhat recently (even though it supported high DPI on other OSes). Unfortunately, someone tried to enable it by upgrading to a new SDL update, and they ran into some issues that seem to indicate that it may still need some improvements on the SDL side.

We’d definitely like to support high DPI on Windows, as long as these issues can be cleared up.

1 Like
#5

Hey, thanks for your in-depth answer, that’s a great help thanks! I didn’t think about looking at OpenFL’s code, but I guess that’s a great place to start!

The above method you mentioned works great.

Regarding HL I did wonder if that would be some kind of SDL issue - I didn’t know what its high density screen support was like. Good luck in getting that working at some point though.

Thanks,
Greg