Bug Why UI Toolkit doesn't support DP units (Android does)?

Both iOS and Android provide the DP/PT unit as described here:
- https://developer.android.com/guide/practices/screens_support
- https://developer.android.com/training/multiscreen/screendensities

But UI Toolkit only provides PIXELS and 3 scaling options where none can replicate DP/PT successfully:

1. [VERDICT: BAD] "Scale With Screen Size": I'm not even going to describe but this will either crop or shrink the canvas UI, so I don't see any use case for this mode (???).

2. [VERDICT: BAD] "Constant Pixel Size": Same here. Basically you design UI on 360 x 640 dp canvas (with e.g. 60 dp = 60 px buttons) and you hope it will scale your buttons accordingly when you switch to 1080 x 1920 px but it doesn't, it's not responsive. Your 60 px button still continues to be 60 px button and it didn't scale to 240 px as it should. I don't see any usefulness of this mode (???).

3. [VERDICT: GOOD IDEA, BAD EXECUTION] "Constant Physical Size":
- This is the CORRECT IDEA (the only scaling mode that should remain IMO), but the execution is BAD.
- You can set "Panel Settings > Reference DPI" to 160 to match Google's definition of "dp", but iOS doesn't use 160!
- And what the hell is "fallback DPI"? It looks like some nasty workaround that shouldn't be there!
- So, if iPhone is 9:16 and has 375 pt in width then you can't just set canvas to 9:16 and design 375 px wide UI in UI Toolkit because you will not be getting the same result as in browsers with

<meta name="viewport" content="width=device-width">

The solution

Unity team: Please give us the final/proper scaling mechanism called "Device-width Scaling" which should obtain DP/PT size of devices as established by

<meta name="viewport" content="width=device-width">

from HTML/CSS.

- In this way we will be able to simply use DP and PT units (PX units can remain in UI Toolkit, no problem with that, CSS also only has "px" and yet you can design websites 100% successfully and easily for any Android/iOS screen size and pixel density).

- We will not have to worry about any "reference DPI" or "fallback DPI" (like web developers don't have to worry at all). What is the problem? Why this is not done like that? Why do we have to specify some "reference DPI"? If I specify 160 then it will work for Android but not for iOS, so it can't be the solution. The "reference DPI" must be obtained automatically by Unity from the same place as Android/iOS obtains content="width=device-width" for browsers.

 

Are you using this mode correctly? I have used it for my entire game UI and it works perfectly on all platforms. How are you using it?

 

Let me visualize this mode the way I understand it:

If you will design your UI on a 360 x 640 px canvas and then try to run that on 360 x 800 px Android device (which can be 1080 x 2400 physical pixels) then it will indeed make your 60x60 px buttons 240 x 240 physical pixel buttons (it will scale them up correctly) but the problem starts when you can't use flexbox and you hardcode for example "320 x 50 dp" banner.

Due to not matching aspect ratios (360 x 640 vs 360 x 800) the banner will get expanded and cropped on sides.

If this is how it behaves then I don't see it being useful for anything other than only small UI components and in rare situations.

 

I don't think I am a rare situation and I have a mildly complex UI system but

I don't know if I did this right, but this is what I got and it seems to work? But maybe I am missing something

This is what looks like your cropping issue. Notice Match: 0.5



This is with Match: 0 and it works

 

Thanks!

However, if we add something with

flex-grow: 1

, like pictured below, then on the actual device, that has mismatching aspect ratio, it will either (1) go down outside canvas (which would be wrong) or (2) do what I drew on the picture (which would make

flex-grow: 1

not work):



So, the "Match: 0" parameter will not help here.

Splitting top and bottom parts of the UXML would also not help because

flex-grow: 1

will not be considered if you split.

So, unless I misunderstand something, it still seems like this mode is probably the least useful of all 3 (like I said in the first post).

 

Dang =(

Yeah I have no clue. I just know it works for others and me. Maybe you have a very unique situation the Unity devs might be more of help. Sorry =(

 

No worries, thanks for your help.

There are several problems in Unity (this is a message to Unity devs):

1. First, is that Unity devs just copied old uGUI mechanisms to UI Toolkit, but they are not aware like (1) HTML/CSS and (2) Android Studio and (3) xCode do this (the modern way). They all use DP/PT units. Unity should too.

2. Unity has "Game" panel, which makes Screen.dpi not available and this is the root of the problem.
- Android Studio only has (1) EMULATOR or (2) PHYSICAL DEVICE - notice that both always have Screen.dpi available.
- So, the "Game" panel in Unity should be removed and Unity should make this like Android Studio did it - only keep the "Scene" and "Simulator" views, so that DPI is always required and then UI Toolkit will not have to have "Reference DPI" and "Fallback DPI" options that come from uGUI and are obsolete.

3. Current UI Toolkit doesn't even allow designing for iOS precisely because the UI design will never be pixel-perfect if you set "Reference DPI" to 160:
- "Reference DPI" of Android is 160.
- "Reference DPI" of iPhones is about 153.

4. I have a fully built UI in HTML/CSS that scales from 320 dp to 1920 dp width and above, so I know what code is needed.
- The canvas of UI Toolkit should always have 100 x 100%. Simple.
- And then with known DPI you can just design UI like you do in Android Studio - in DP units. Simple.

So, in conclusion: UI Toolkit uses outdated methods and Android Studio uses proper methods. Unity devs should upgrade to the methods from Android Studio.