I've had a look into getting this implemented, high DPI mode can be switched on now using the org.lwjgl.opengl.Display.enableHighDPI switch:
e.g. as a VM parameter using:
or in java code before creating the Display:
However it seems that the way its implemented on OS X may not be usable without at least adding some new LWJGL API or internal modifications to LWJGL. Windows 8 also seems to have taken the same approach with their implementation of high dpi resolutions.
On retina screens, any app that does not explicitly opt into the high dpi mode will be scaled up (currently twice the size as retina apps i.e. 4 pixels represent one scaled up pixel) and will work as normal (as it did on non-retina screens). If you do opt into the high dpi mode then the OpenGL frame buffer uses the retina resolution but the mouse position and window sizes continue to use the scaled up sizes (currently half the size) i.e. the Display.getWidth()/Display.getHeight() will return sizes half that of the frame buffers pixel size. This behaviour is probably intentional to stop apps get smaller at higher resolutions but instead just looking sharper.
Problem is methods such as glViewport, glScissor, glReadPixels, glLineWidth, glRenderbufferStorage, glTexImage2D which often get their pixel information from Display and Mouse can no longer use these without the values first being modified.
1) Internally scale the Mouse and Display.getWidth()/getHeight() values to match the real retina resolution and OpenGL frame buffer size, seems easy to do but all apps not adapted for this behaviour will appear tiny (half their normal size) on retina displays.
2) Catch values sent to all pixel dependant OpenGL methods and scale them appropriately, seems ugly to do (with the lwjgl generator) and not sure it'd be workable for stuff like shaders.
3) Push the burden on to developers with some new LWJGL API so they can do the calculations themselves when opting into high dpi mode.
e.g. give them the size of the OpenGL Frame Buffer with Display.getFrameBufferWidth()/getFrameBufferHeight() or something like giving them a Display.getFrameBufferScaleFactor() which will return 2.0f when in retina mode (or whatever the DPI ratio is) and 1.0f when not in retina mode so dev's can do something like
when passing values to pixel dependant opengl methods.
Any idea's on a good direction we can take on this? more info here