Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
  3. Join us on November 16th, 2023, between 1 pm and 9 pm CET for Ask the Experts Online on Discord and on Unity Discussions.
    Dismiss Notice

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

Discussion in 'UI Toolkit' started by twell59, Aug 27, 2023.

  1. twell59

    twell59

    Joined:
    Feb 6, 2016
    Posts:
    25
    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.
     
    Last edited: Aug 27, 2023
  2. TomTheMan59

    TomTheMan59

    Joined:
    Mar 8, 2021
    Posts:
    315
    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?
     
  3. twell59

    twell59

    Joined:
    Feb 6, 2016
    Posts:
    25
    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.
     
  4. TomTheMan59

    TomTheMan59

    Joined:
    Mar 8, 2021
    Posts:
    315
    I don't think I am a rare situation and I have a mildly complex UI system but :p

    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

    Screenshot 2023-08-28 at 9.58.34 AM.png

    This is with Match: 0 and it works

    Screenshot 2023-08-28 at 9.58.42 AM.png
     
  5. twell59

    twell59

    Joined:
    Feb 6, 2016
    Posts:
    25
    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).
     
  6. TomTheMan59

    TomTheMan59

    Joined:
    Mar 8, 2021
    Posts:
    315
    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 =(
     
  7. twell59

    twell59

    Joined:
    Feb 6, 2016
    Posts:
    25
    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.
     
    PanthenEye and TomTheMan59 like this.