[FIXED] JAWT interface exception on Mac OSX with Java 7

[spasi]

JavaFX 2.1 comes bundled with JDK7u4 and is available now for both Windows and MacOS. AFAIK, it will be pushed to all MacOS users in early May. In 2.2 applet/JWS support will also be added (on MacOS).

Anyway, a clean Cocoa solution would be cool for standalone, but it's still going to be half-arsed for applets. A JavaFX solution would also be beneficial for the other 2 OSes, since we'll have to integrate with it sooner or later.

Btw, are you saying that JavaFX applets will be going through the same slow rendering path?

[kappa]

Btw, are you saying that JavaFX applets will be going through the same slow rendering path?

Yes they'll have to, as CALayer is the only way to draw in a browser on OS X now (even Flash, Unity3d, etc have moved to it). The Oracle engineers might even decide to use the CALayer as the only method and take a bit of a performance hit for standalone JavaFX application. Do note if you have direct access to the Cocoa API (like Unity3D, Flash and probably JavaFX) then you can avoid the double performance hit as you can use the CALayers OpenGL context directly (which would run at acceptable speeds) unlike through JAWT where its hidden to LWJGL and we need to use the slow pbuffer trick to make it work (which is really the major performance killer).

[spasi]

OK, then it makes sense to go with Cocoa now and consider JavaFX integration later, when it has matured a bit.

[princec]

It's really got to be done properly I think using the Obj-C APIs or it's just going to remain fragile. But has anyone frequenting here got any proper OSX Obj-C development experience?

Cas

[kappa]

Contracting out the task looks like the way to go, at least for those with a financial interest in LWJGL on OS X.

We'll need someone who has the following skills:

Solid Knowledge: C, Java, Objective-C, JNI, Cocoa and OpenGL.
Basic Knowledge: SVN, ANT, Carbon.

In-depth knowledge of Cocoa and its threading model is required as it is pretty tricky to get a standalone Cocoa app running through JNI plus we probably want the application to be nibless (to at least allow easy building on the nightly server). Knowledge of OpenGL with both NSView and CALayer(NSOpenGLLayer) is recommended. NSView will probably be the main way to render but we'll probably want the CALayer option too to allow embedding in AWT (for stuff like Applets, Display.setParent, etc). There is already a surprising amount of Cocoa/Objective-C in the current code base so should be useful in some way.

The LWJGL Display does do a few things which are not supported by the Cocoa API (like mouse grabbing, etc) using the Carbon API, these bits can just be reused from existing code base to keep the functionality. Knowledge of OpenGL contexts is also vital as that part is mostly done in C in LWJGL to allow code sharing between platforms. So mostly it will be a task to replace all the AWT window parts with a pure Cocoa window implementation.

Target Platform: Support for OS X 10.5+ on both 32bit and 64bit systems (time we really dropped PPC, OS X 10.3 and OS X 10.4).

I reckon someone with enough skill should be able to wrap it up in about 2 weeks, thereafter idling for a few weeks on the forums to fix any reported bugs.

[princec]

Hmm where would be the best place to advertise it? Ideally a volunteer with a vested interest would be able to do it.

Cas

[kappa]

JGO would be a good place to start, could also reach some wide coverage through twitter with some targeted tweets.

Wonder if some of the old LWJGL contributors like elias naur or kevglass would be interested in some contract work or something (both have solid expertise in the required areas). Other experienced Java vets like David Brackeen (does contract work) might be interested but who knows, will really depend on what we have to offer.

[princec]

I'll ask Kev.

Cas

[princec]

http://www.puppygames.net/blog/?p=1112

Cas

[abcdef]

Are you looking for someone to basically implement this

https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html

?

Seems to have all the things you are interested in, using objective c, NSView etc

I have a Mac with xcode, know java and jni but not so hot on the object c side of things

[Dan]

I took a look at the original problem and I have some more info.

"JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM"

The message is comes up due to the fact that your lwjgl native libraries were built against the 1.6 apple jre. If you are trying to use the jdk7 jre with these incompatible native libraries, you will receive that error. It's telling you that the 1.6 apple environment has not loaded yet, which is unfortunate but expected behavior.

I pulled jdk7u and built the lwjgl native libraries against it (after some hacking). My app launched a window, but the content area with my opengl surface was blank. To make a long story short, lwjgl will not work with jdk7u at all.

The long term solution is to implement a native cocoa window in lwjgl. For the short term, getting lwjgl compiling and functioning (even if there is performance problems) would be a good idea.

I certainly have the skills and the interest to do this work, but my time is somewhat limited with family, job, etc. I will try to look into the solution this week (hopefully).

[princec]

Dan - that'd be great. Let us know when you're ready to start.

Cas

[Obsyd]

Cas: "Aha, Mojang have woken up… there is progress inching forward in this area."

Ahh great news!! I got really scared that lwjgl on osx is in trouble.

I wish I knew enough of java to help...but I don't

[void256]

Any news on this yet? I'm running into the same issue now :/

Additionally I too could offer help in this area. I have Java, JNI, Xcode, Obj-C and OpenGL/LWJGL experience but I'm not really a seasoned OS X developer. I've ported/created quite a lot of code to Obj-C/iOS last year for my day job though (this was Security/UI related stuff and not OpenGL/Graphics related at all, unfortunately).

[abcdef]

Just checking in on progress? are there people actually working on this? I wouldn't mind trying to help out on this, is there any help on what needs to be re written? I've had a look at the code and can see where the old context code is loaded, should the java part of it work more like Linux and windows now?

In ContextGL.java there is

properties.put(APPLEGLSharing.CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE).put(CGLShareGroup);

but for windows and linux there is a context property and a display. I don't know how this is used to know exactly whats required.