[FIXED] OSX / Java 7

[UlfJack]

While you're at it, how about retina support? Non-retina OpenGL looks awful.

[voidev]

I am from germany and playing around with jPCT.

my environment:
MBP 2010 i7 (german version, qwertz kb layout)
OSX 10.7.5 (german version)

I would like to assist your impressive work with a minor bug report.
It looks like the new keyboard handler doesn't take the keyboard layout into account.
e.g. y and z are inverted on qwertz

With Java 6 and the original lwjgl 2.8.5 release the 'y' keystroke is correct (on my german qwertz keyboard layout).
If I then replace the original libs with the libs provided from kappa (latest experimental build), the 'y' keystroke is wrong. The game code receives a 'z'.
And vice versa. Same "problem" (y<->z) with Java 6 and 7.

Let me know if I can assist with other tests on my environment. (full of expectations on the AWTGLCanvas stuff)

[pizza2004]

While you're at it, how about retina support? Non-retina OpenGL looks awful.

I don't know if that could be built directly into LWJGL, it seems like it's something that would need to be done by the program itself.  I don't really know a ton java, or how retina display actually works, so I'm going to look into the issue and see if I can find anything about this.

Edit:  Some preliminary searching shows Apple updated Java 6 to use native frameworks entirely a while ago (it avoids Sun2D) so it has no issue with it, however Java 7 does.  I have little experience with programming, and none with Java, however, it seems like any attempt to get the standard function we have now in LWJGL that uses AWT in Java 7 will be more of a workaround than anything on Mac, and given Java 7 apparently doesn't support retina display, and it's difficult to tell if it will anytime soon, using Java 7 to run anything probably won't work.  We should be able to get it running in the Apple version of Java 6, and there are a few places that talk about that:

http://apple.stackexchange.com/questions/53741/java-and-mac-retina-support

[adamk33n3r]

Question: Are there any plans for using the new OS X style of fullscreen, if possible?

[Freezerburn]

Question: Are there any plans for using the new OS X style of fullscreen, if possible?

This is something that was built into one of the releases of Java when Lion came out. I don't know if LWJGL should have support for this or not (that's something only the devs should/can decide), but you can definitely put this together in your own application right now if you use Display.setParent. This SO question should give you all the information you need to know: http://stackoverflow.com/questions/12751704/how-to-have-a-jframe-maximise-icon?lq=1

[pizza2004]

Wait, I just noticed, Java 7 uses dylib by default now instead of jnilib.  Based on the fact that when I finally did get it to load with Java 7 the old jnilib format still works, but I'm wondering if maybe we could build a 64 bit Java 7 version as dylib after we build the Java 6 32/64 bit versions.  Also, I don't think it's been mentioned, but Java 7 on Mac does not have a 32 bit version, this could possibly be because a 64 bit processor is required in OSX Lion and up, so there wouldn't be much point in releasing a 32 bit version for platforms that require 64 bit anyway.

Here's the second issue:  By default, LWJGL is going to want the full JDK installed on Mac in order to run with Java 7, due to the differences in how Java 7 is implemented on Mac versus Java 6.  Basically, installing the JRE seems to only install a copy of the internet plugin, which is located in a different place than the JDK, and you have to build against a specific location for the libraries to sit otherwise it won't know where they are.  The main problem being that I also don't have any idea how to package the JRE with LWJGL in a way that allows it to work like it needs to.  I'll keep looking at things to see if there is another way, but I'm not sure if I'll have any results.

[UlfJack]

Edit:  Some preliminary searching shows Apple updated Java 6 to use native frameworks entirely a while ago (it avoids Sun2D) so it has no issue with it, however Java 7 does.  I have little experience with programming, and none with Java, however, it seems like any attempt to get the standard function we have now in LWJGL that uses AWT in Java 7 will be more of a workaround than anything on Mac, and given Java 7 apparently doesn't support retina display, and it's difficult to tell if it will anytime soon, using Java 7 to run anything probably won't work.  We should be able to get it running in the Apple version of Java 6, and there are a few places that talk about that:

http://apple.stackexchange.com/questions/53741/java-and-mac-retina-support

While you're right that AWT and Swing support rendering on a retina display (though it is not possible to detect reliably whether retina is en- or disabled, so no sharp images or double-buffering), OpenGL appears to be a different story. Apparently, you can only get high-DPI rendering with OpenGL using CocoaGL, and you need to enable it explicitly with setWantsBestResolutionOpenGLSurface (whatever that means, exactly):
http://www.opengl.org/discussion_boards/showthread.php/178916-Using-the-retina-display-on-a-macbook-pro

Also see:
http://markmail.org/message/ceydhtlvzes7geqw
http://lists.apple.com/archives/java-dev/2012/Jul/msg00010.html

[pizza2004]

@UlfJack Well, but aren't we reworking it to use Native Cocoa now instead of having to rely on Java things?  So wouldn't that work anyway?  Isn't what you're saying a good thing?  Why does it sounds like your saying it in a letting us down kind of way...

[delt0r]

I seriously don't understand. Why does there need to be special support for retina displays. They are not magic, just high resolution. Opengl should have no issue with that.

Since i am now somewhat forced to work on a mac for a while, I am much more interested in the state of the mac support. Since we all have retina displays, it kinda needs to work with them. But then again the fill rate of the cards tends to be on the low side for such resolutions IMO.

Also the term retina is terrible.

[pizza2004]

@delt0r The reason there has to be special support is due to the way OS X handles retina display.  By default it uses 1/2 the actual resolution, and just tells the operating system to treat the display like every 4 pixels are one pixel.  It knows the difference however, and it's possible to bypass this, by using .5 instead of 1 to refer to an individual pixel.  So yeah, the reason it needs special support is because you have to tell your program it's 2x the resolution that you're program can see and then output things to half pixels instead of regular pixels.  I'm not even sure what happens if the people decide they want to use one of the 3 or 4 other scaling options available through retina displays.

[delt0r]

Sounds totally retarded. Why would they do that. Its not even like they are that high a resolution.

Still I never need to consider pixels with opengl. I just care about polys. Sounds like there is almost hardware abstraction.

[pizza2004]

I wouldn't say totally silly, it's so that programs stay the same size instead of becoming tiny on your display.  So basically, first you have to tell the OS you're capable of displaying in HiDPI, and then you have to act like you're printing to 1/4 size pixels to hit the actual pixels.  I think it's so the system doesn't have to try to interpret things several different ways just because one program is high resolution and one isn't, it just has to act like 1 equals 4 pixels instead of just one, and 1/4 equals one pixel.  Is it the best way to handle things from a developer point of view?  Probably not.  It still makes some sense though.

[princec]

Surely a getDPI() api call would have been more sensible. Then we could simply choose what to do ourselves. There are three two metrics for a display: its resolution, and its density. So perhaps getDPI() would be an extremely useful addition to LWJGL; and we'd return actual physical pixel sizes from getWidth()/getHeight() under any OS.

Cas

[delt0r]

[ot]
[rant]
I write all my programs to be as resolution independent as possible. What the hell a TT Fonts for if not to be resolution independent! its 2013 and we need a different version of every app for different screen resolutions? seriously?
[/rant]
[/ot]

[abcdef]

rant away but this isn't lwjgl's fault its apple's and the way it implements its OpenGL canvas.

There is a simple fix though

https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW33

Its just adding

[self  setWantsBestResolutionOpenGLSurface:YES];

To the NSOpenGLView implementation