[BUG/RFE] Make Display.getPixelScaleFactor work before Display.create

[samskivert]

Right now Display.getPixelScaleFactor returns 1 regardless of what the actual scale factor is, until you call Display.create at which point it returns the right value.

It would be useful if we could find out what the desktop scale factor was before we created our window. In my case, I have a game framework (PlayN) which supports developing for desktop, iOS, HTML and Android, and I want to make it easy for developers to test their HiDPI code on the desktop. So I want to know, before I create my window, whether I need to simulate HiDPI mode by making everything twice as big, or if they're already running on a HiDPI display, in which case I can just use the native HiDPI support.

But if I have to wait until after I've created the window to do that, I have to resize the window after it's created, which looks crappy. FWIW, on Android and iOS one can find out what the device scale factor is before they open up any windows.

Based on the way Display.getPixelScaleFactor() works, maybe this means another method is needed which just calls right into [[NSScreen mainScreen] backingScaleFactor] (maybe Display.getScreenPixelScaleFactor()) because the other code path pushes the scale factor out to a cached Java value, presumably so that calling Display.getPixelScaleFactor() is fast.

I can send a patch for the Mac OS code. It doesn't look like the pixel scale factor is even wired up on non-Mac platforms, so presumably stubbing that out for other platforms would be OK.

[kappa]

Based on the way Display.getPixelScaleFactor() works, maybe this means another method is needed which just calls right into [[NSScreen mainScreen] backingScaleFactor] (maybe Display.getScreenPixelScaleFactor()) because the other code path pushes the scale factor out to a cached Java value, presumably so that calling Display.getPixelScaleFactor() is fast.

Could also be called once initially in a static initializer inside the MacOSXDisplay class rather than on Display.create().

I can send a patch for the Mac OS code. It doesn't look like the pixel scale factor is even wired up on non-Mac platforms, so presumably stubbing that out for other platforms would be OK.

Yeh, Hi-DPI displays aren't yet that common on other platforms so only been implemented on Mac. A patch would be nice and much appreciated.

Alternatively you could make the jump to LWJGL3 which has much nicer Hi-DPI and multi-monitor support (including for non-mac platforms). It also expose the unsafe long pointer versions of calls to GL, AL & CL which might be useful for PlayN.