Am I correct that openfl.system.Capabilities.screenDPI isn’t working in the newest OpenFL? Peeking at the source code, it seems like there’s a quick trick used to get the DPI under HTML, but on all other platforms the DPI will be set to zero.
My entire app relies on initialization code that computes layout based partly on screenDPI, meaning that right now nothing works at all. Should I stick with legacy/v2/hybrid for now, or is there some other 3.0 means of obtaining the screen’s physical dimensions and resolution?
We need to add some APIs to Lime 2 to allow listing the 1.) connected displays, 2.) detecting the current display for your window, 3.) getting the available display modes, 4.) getting the current display mode and 5.) getting the current display DPI
It’s more a matter of where to put it than how to, since SDL2 makes checking these values pretty simple.
Perhaps we could have it implemented soon (ideas are helpful… something under lime.system.* somewhere?) or we could at least stub in a default 72 or 144 value
Yes, lime.system was the first place I looked, so that seems right (with lime.graphics as a runner-up). I imagine you’d want a Display class that describes a single display and contains static methods for telling me about the current default display and for obtaining a list of all connected displays. Then I suppose each display could tell you about its supported modes.
I’ve never used SDL directly, but I’m glad to hear that it’s easy to do all this stuff. (Looking quickly at the API, I couldn’t see an obvious way to obtain the current DPI, but I assume it’s in there somewhere.)
Hmm, yeah, I suppose SDL returns display resolutions, but not density. Basically, then, we have platform-specific ways of getting the monitor measurements, then we calculate the density based on those two values
screenDPI is a necessity for Mobile development. It is not possible to create a DPI free UI application without it. When it will be added to framework?
At libgdx they just take it from Android Metrics (androidDensity). However, openfl will implement it in a different way if I understood it right.
I think this is new in a version of SDL on their source repository, newer than the one we use. If this becomes stable, then I think this would be a shoe-in for implementing this functionality
Does anyone know if there’s been progress on this? HypSystem is fine, but totally overkill for my needs, where I just want to know the density and don’t need the rest of the library (which for at least one user in their github issues makes their project crash.)
Yep, it should. It may be hard-coded for Windows, but (I think?) is real for mobile or maybe OS X, it depends on the SDL support of this across its supported platforms
