Multi-DPI support

[RealyUniqueName]

Have to find clear idea how to implement this with minimal impact on initialization and gui-creation processes.

[bsortuser1]

I have implemented a very simple solution in my clone of your repo. It is not done yet though, haven't gotten around to fixing Scale3 and Scale9 skins.

But the idea is that we load in different image sources via our own Assets class which we then scale down to a ingame size. Everything is drawn with this in game size and that is what you always work with when designing everything. Then everything is scaled up again automatically using the display tree.

The only thing I have done with StablexUI is that I have added a variable in your Assets class which is the graphics to ingame size ratio, everything that uses images in StablexUI uses this ratio to scale down the images properly.

This is the commit https://github.com/goleegrees/StablexUI/commit/ad83c56274bf3bcc5011c5d709286bd72fc72d41

What do you think about this solution? Not especially fancy :)

[RealyUniqueName]

I like this idea from "stock-StablexUI-user" point of view because it does not require any additional configuration and i also don't have to keep in mind different DPI's.

But i don't like this idea (or it needs some improvements) from "StablexUI or custom widgets developer" point of view as it requires me to add these dpi-aware code blocks everytime i create new widget class or deal with positioning/sizing widgets.

Thanks for your suggestion! I'll try to investigate more with it :)

[bsortuser1]

Perhaps a custom Bitmap-class or something that handles the scaling, and that one have to use if they are implementing their own widgets and want multi-DPI support?

[kamiltoszek]

On android, when it comes to images, it is resolved by having separate resources folder for groups of dpi sizes. More important I think is to move from pixel based units to unit based units.. this includes font sizes too. IMHO this is more important at the beginning.

[RealyUniqueName]

I think, unit-based system may be the solution.

[ejazasghar]

i have used both autoscaling (like Flex does) and manual scaling (like Straling-Feathers UI) does, and manaul scaling is best, because sometime u want to scale your UI only and leave other things as it. for example, i recently developed a drawing app using flex, and flexed scaled the bitmap along with UI so i wasnot able to take advantage of retina display, and my drawing app output same image size on both iPhone 3 and Iphone 4 (retina) but feathers on the other hands, provides a theme, where scaling is handled (manually/on theme basis) and leave users to either scale content or not. You may want to look into Feathers UI MetalWorks Theme's source code and how it is taking care of scalling

[rockswang]

For unit approach, see my new issue #68

[galluccipablo]

I like the Starling stage size approach for handling multi-resolution/density screens. I can set the Starling stage size manually, e.g. 320x480, and all positioning code use this size. So, if I initialize Starling for using the entire screen, no matter what device it is or real screen size it has, my application code will always be based on the stage size I set for Starling. And no need to hard code a size, it can be set at runtime, so I usually set 320 for the width and a proportional value for the height (something between 480 and 533 for most of phone screen sizes). This simplifies a lot the setup code for application views.

If StablexUI implements something like this, e.g. setting a stage size and handling its own coordinate system, we would not have to worry about different defaults for different screen sizes. The major problem I see is that StablexUI is not a full application framework, so using its components in a view hierarchy not using this coordinate system can be a problem.