JOGL on Mojave, Mac OS 10.14

Ooops - you know what - I just found out that the MembraneEditor still of course crashes, but our CellExplorer which is of the same complexity and uses the same JOGL/Java3D technology, does not! The graphics looks a little bit dirty though, especially the 2D elements on top of the canvas. The 3D elements just seem to be lacking any anti aliasing but this is normal on Mac OS X. But is runs!

So I have to find out what is going wrong with the MembraneEditor ...

Extended Remark: This does not apply to Java 11 - the CellExplorer runs on Max OS X Mojava with Java 8, interestingly the MembraneEditor fails here already with Java 8. With Java 11, the described error messages occur.

Thank you for the feedback, yes it confirms a bit my suppositions.

Do you think this is a Java 11 bug which might be solved in the near future or do you think we need to think about a workaround?

You can already get rid of most illegal access warnings with this:
http://forum.jogamp.org/JOGL-Java-10-modularization-tp4038983p4039284.html

The last warning about NSWindow can be fixed in JOGL itself as I wrote here:
http://forum.jogamp.org/JOGL-on-Mojave-Mac-OS-10-14-tp4039037p4039257.html

Perhaps the crash occurring when releasing the native resources can be fixed in JOGL too but as I have no machine under OS X 10.14, I have no way of reproducing this bug :s

Actually, maybe my first suggestion of fix would fix the real crash too. Are you able to build JOGL to test some changes?

Hi all,
revisiting the problem for a paper, I managed to get my MembraneEditor temporarily working on Mojave. But I had to do some dirty tricks and it is not reliable. So I found out, if the 3D view in the starting configuration is relatively small, let's say 1/4 or 1/5 of the screen, the application does not crash during the starting procedure. Afterwards I can resize the Canvas3D without the error to occur. (So if I want to downsize the window, I hide the JPanel on top of which the Canvas3D resides, resize the window, safe configuration, and restart with small window and making the JPanel visible - and also I make sure that the JPanel is set to visible after all other GUI elements have been shown - at the end of the process).
So question: I am currently using in this configuration Java 3D 1.7.0. So does it makes sense to switch to 1.6.2 - could it help at all? It takes then again an hour of refactoring.
Best,
Bjorn

Please try Java3D 1.7.0 with the latest nightly build of JOGL 2.4:
http://jogamp.org/deployment/archive/master/gluegen_915-joal_641-jogl_1479-jocl_1119/

Thanks Julien again, I will try!

So I used now the new JOGL version 2.4.0 with Java3D 1.7.0_pre1.

(I also saw that there seems to be the source code for 1.7.0_pre2, but no compiled version by now?)

However, this solved indeed these warning messages:

2018-11-20 15:45:07.610 java[11053:268633] WARNING: NSWindow drag regions should only be invalidated on the Main Thread! This will throw an exception in the future. Called from (
        0   AppKit                              0x00007fff42af1824 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
        1   AppKit                              0x00007fff42aeebd0 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
        2   AppKit                              0x00007fff42aee5fa -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
        3   libnativewindow_macosx.jnilib       0x000000010da733fe Java_jogamp_nativewindow_macosx_OSXUtil_CreateNSWindow0 + 398
        4   ???                                 0x000000010e80f9f4 0x0 + 4538300916
)

This message did not appear anymore.

However, the previously described problem is not solved:

org.jogamp.java3d.IllegalRenderingStateException: Unable to make new context current after 5tries
        at org.jogamp.java3d.JoglPipeline.createNewContext(JoglPipeline.java:6429)
        at org.jogamp.java3d.Canvas3D.createNewContext(Canvas3D.java:4602)
        at org.jogamp.java3d.Canvas3D.createNewContext(Canvas3D.java:2376)
        at org.jogamp.java3d.Renderer.doWork(Renderer.java:881)
        at org.jogamp.java3d.J3dThread.run(J3dThread.java:271)

DefaultRenderingErrorListener.errorOccurred:
CONTEXT_CREATION_ERROR: Renderer: Error creating Canvas3D graphics context
graphicsDevice = sun.awt.CGraphicsDevice@6a3e1b49
canvas = org.cellmicrocosmos.cm2.functionality3d.Membrane3D$1[canvas0,0,0,32x-149]


Looking to the original code in the JoglPipeline, this is what is written there:

     
    // Apparently we are supposed to make the context current at this point
        // and set up a bunch of properties

        // Work around for some low end graphics driver bug, such as Intel Chipset.
        // Issue 324 : Lockup J3D program and throw exception using JOGL renderer
        boolean failed = false;
        int failCount = 0;
        int MAX_FAIL_COUNT = 5;
        do {
            failed = false;
            int res = glContext.makeCurrent();
            if (res == GLContext.CONTEXT_NOT_CURRENT) {
                // System.err.println("makeCurrent fail : " + failCount);
                failed = true;
                ++failCount;
                try {
                    Thread.sleep(100);
                }
                catch (InterruptedException e) {
                }
            }
        } while (failed && (failCount < MAX_FAIL_COUNT));

        if (failCount == MAX_FAIL_COUNT) {
            throw new IllegalRenderingStateException("Unable to make new context current after " + failCount + "tries");
        }


MAX_FAIL_COUNT is used there trying to fix the problem, and in some cases it obviously works, and in this case now it don't. So maybe it would work if the value would be increased. Also, tweaking the Thread.sleep might be a way to fix the problem.

As my Mac Book Pro has an Intel (Wannabe Graphics) Chip, this might be indeed exactly the problem.

It's tricky! ;-) Any ideas, other than to change the source code of the JOGLPipeline completely and recompile?

 

Please be a lot more accurate about your graphics chip to give us a chance to reproduce your problem. I don't think that increasing MAX_FAIL_COUNT would help. Other JOGL backends in several engines use the same kind of workaround. Does a very simple example using only JOGL work on your machine?

Yeah, sorry, sure:
Intel Iris Graphics 6100 1536 MB
And yes, small programs with JOGL run.

JogAmp's Ardor3D Continuation uses a similar workaround, maybe you should give it a try. If it just works, then we'll have to port some code from JogAmp's Ardor3D Continuation into Java3D if possible.

Note that this isn't a JOGL specific problem.

Hi,

I believe this should be fixed with this commit:
https://github.com/sgothel/jogl/commit/1c697274a3c1e976bd9c9b089d6583edf4f346ae

Best regards,
Bogdan

Hi Bogdan,
thanks for the hint - though not sure if it can fix the problem, as it is NEWT-related and Julien mentioned that this is not JOGL related problem. However, is there a latest build I could try?
The last autobuild seems to be from 2019-04-10:
http://jogamp.org/deployment/autobuilds/master/

Bogdan showed the fix of a problem affecting Andy, you have another unrelated problem.

Thanks, Julien! I think it's time to shut up from my side and solve the problem - I will let you know when I succeeded ;-)

You're welcome but don't shut up. Your feedbacks are valuable.

Hi Julien, yeah, but sometimes it is more productive.

Thanks in any case for your comments!

If you like, you can test the app here:
https://www.cellmicrocosmos.org/index.php/start/startcm2
Look for the ZIP file of
Java 8: MembraneEditor 2.2.2_3beta01
It was by now build and tested on Mac OS X 10.14.4 with Java 1.8.0_131. So it would be interesting to know on which other systems it is starting. You just have to install it and look if the 3D view in the center of window appears. On Mac OS X, it might terminate after the first start. Just by restarting, everything should work fine.

So, I found a workaround, and it was a GUI problem. I think it is highly specific and posting the solution here will not help anybody else. But interestingly: when my software was correctly shut down in maximized mode, it tried to start in maximized mode, and crashed. What I do now: I delay the start, hide first the 3D University with JOGL Java 3D 1.7.0PRE1, and after the GUI is fully created, I show the 3D view.

I do this by Threading (2nd Thread is waiting for 1st one to finish) and adding two additional Thread.sleep(1000);.
The 1st Thread shows the 3D Universe, which has been created before, but which has been hidden.
The 2nd Thread restores the layout.

However, interestingly, if the window was maximized before, the window was only re-launched as a very small frame. I just make sure now to force - in case the window is too small - that it is maximized again. But as I said, I think this is a very specific problem of my window manager and the layout library I am using.

Tests on this version:
Mac OS X 10.14.4 with Java 1.8.0_131 64 bit: runs
Windows 10 64 bit with Java 64 bit: runs
Windows 10 64 bit with Java 32 bit: fails
Ubuntu 64 bit 18.04: fails

I'll run it at home under Mageia Linux soon.

As promised by Apple, this problem now throws an exception in MacOS Ventura (released to the public on Oct 24 2022).

Consequently, my apps that use JOGL, and I am sure many others, not longer launch on this OS.

Is there a known fix?  Please advise

-- Dave

Hi,

I don't exactly know this issue but I can say that using a 2.4.* JOGL version saved several issue on macOS for me.

I however encountered latency issues with Newt and kept Swing or AWT canvases in my applications.

This version may be the best as it includes binaries for Apple M1 as well. You can get it both via maven or by downloading the ZIP archive.