[FIXED] OSX / Java 7

[macdonag]

More bug fixes in now, hopefully two more of the native crashes are fixed, one of the startup ones (the "Collection <__NSSetM: 0x7fa13b485c50> was mutated while being enumerated.") and another on exiting the app (although there is now a different crash on exit which only happen when using the red x close window button, can be silenced but better to fix the root cause once found).

Been using it for the last hour or so, without any of the enumeration crashes - thank you very much!

[kappa]

Another update, cleaned/removed a lot of the redundant LWJGL OS X code left over from the previous implementation (thx @Grum for providing an initial patch diff).

Implemented missing mouse movement events when dragging the mouse with either the right mouse button or the other button (thx @avm1979 for spotting and reporting).

Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip

[ajr_1]

Hi kappa,  just tried this newest build. 

Firstly, on Java 1.6_037 in Eclipse.  When run as an application rather than an applet it worked in general, although the mouse scroll wheel didn't work.  It did crash on exit though, crash report is attached.  As an applet, it crashed on loading, report attached.

Then with Java 1.7_09 in Eclipse.  When run as an application it worked apart from the scroll wheel.  It also crashed on exit, report attached.  When run as an applet it crashed on startup, report attached.

Let me know if you need any more info.

[kappa]

Thanks for testing, scroll wheel is currently intentionally disabled as it was using an OS X 10.7+ Cocoa API, but will be fixed soon, just a matter of plugging in the older OS X 10.5+ Cocoa scroll wheel API.

The crash on exit is also known but why it happens is still a mystery. It crashes in the native method 'lockFocus' when calling 'setView' inside Display.m (if you comment out that call it works fine and doesn't crash), this is because the method is called once the window is destroyed/closed as something is making another draw call. This only happens when the red x close button is pressed on the nswindow. The crash stack trace seems to suggest that [AWTStarter starter:] is what is calling the redraw once the close button is pressed, however don't see in the code where this is being started from, any idea's are appreciated (maybe some sort of AWT thread started automatically by the OS X JVM?).

As for applets, they won't currently function with the above builds, as the old applet code used to make them work has been removed. Focus is on getting the native Display stable first. Spasi is working on a new experimental offscreen drawing method for LWJGL 3.0, which we'll backport to re-add this AWT functionality in the LWJGL 2.9 release.

[void256]

The latest build that kappa posted some days ago here works a lot better for me. I've not seen crashes anymore and I can actually close a LWJGL window with cmd+q without the window staying open hanging.

Basically I just want to say thanks and keep up to good work! It looks a lot better now!

[refD]

Tried the latest build, (14 Nov),

Still getting
"[info] Window handle is null
[info] Resizeable" output to my console and it pauses while trying to Display.create.

I've tried varies versions of Display.create, various pixel formats, and core/compat profiles, none make a difference

Running 1.7.0_09 this time.

Using JRE6 for this LWJGL build works fine (until a crash on close), so there doesn't appear to be anything deeply flawed with my setup.

[kappa]

Finally found and fixed the native crash on exit.

Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip

[adamk33n3r]

Hey kappa. I found a crash in OS X when trying to enter fullscreen. I was following the basic tutorials on the site and I was on the FullscreenExample one. Well anyways, when entering fullscreen it crashes and gives the error log I attached saying it is a crash in the native code.

I did some experimenting and I found that on rare occasions it enters a pseudo-fullscreen. It is like a window with no borders, anchored in the bottom left of screen, but only the size of which was specified, in my case 800x600. Another thing I tried was starting out in fullscreen which produced the same effect as just described every time. But when switching out of full screen and then back it would crash again.

Hope this helps

BTW I'm using Java SE 7 and Mountain Lion

[kappa]

@adamk33n3r - thanks for the crash log and detailed description, will have a look into that.

[adamk33n3r]

@kappa Ya hey no problem. I'm glad I can help.

[adamk33n3r]

Just an update. I tried it on Java 6 and it crashed as well

[refD]

Alright, I worked out what was causing my crashes.

My problem was that I was creating my own java.awt.Canvas and Frame, and parenting them manually. I guess that means Diaply.setParent functionality has changed.

I've removed all that code (just letting LWJGL handle it), I'm creating the Display the straight forward way and I'm no longer getting any crashes.

I'll go about getting full screen, resizing and mouse grabbing working again and see how I go.

[Petr Pchelko]

Hello everyone.

I work in the OpenJDK AWT team and I am looking at this bug currently:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169339

However, as I see from this topic, you do not need anything from our side already as you've almost implemented all the functionality in Cocoa.
Is that true? Do you still need this functionality to be implemented or any other support from the JDK side?

Best, Petr Pchelko.

[princec]

It appears progress is being made but it'd be great if you could work with us on any tweaks or fixes in this area.

Cas

[kappa]

@Petr Pchelko thanks for dropping by, we have indeed had to reimplement all the functionality for standalone applications in pure Cocoa (basically bypassing AWT) . We had used AWT as our windowing system for over 10 years, it worked well as we just grabbed the NSView of an AWT Canvas and stuck an OpenGL context on it.

Apple made changes when they moved to lightweight AWT widgets (starting from Java Applets and now I think its also used for desktop AWT applications in Java 7). The reason this broke was there was no underlying NSView for AWT Canvases anymore or method to stick an OpenGL Canvas on it.

Apple did later add a JAWT method to add CALayers (thus allowing NSOpenGLLayer) but this isn't really suitable for Java OpenGL bindings because it forces all opengl calls and rendering to be done inside NSOpenGLLayer's drawInOpenGLContext method, so not feasible to do that from the Java Thread without serious hackery to fit all OpenGL calls into that method during the limited time slice its given to render.

We still need a better method or API for AWT integration of OpenGL Contexts for Java OpenGL bindings without needing to resort to hackery to make it work (like on Windows and Linux).

LWJGL integration with AWT Applications and Java Applets would still be nice and likely wanted and needed by users but with the current JAWT/CALayer API the only feasible way to use it is to internally use a PBuffer (now depreciated on OS X) as a shared context with the NSOpenGLLayer context then render to texture on LWJGL Display update (which has a large overhead) and then draw the texture in the NSOpenGLLayer. It would work but ends up being slow, buggy and adds a bit too much hackery insider an otherwise simple OpenGL binding.