Creating a JFileChooser dialog when JOGL's is using NEWT, results in the dialog being behind of the GLWindow. Tested on Mac OSX 10.9.5 only so far. This is the test code that reproduces the issue: https://github.com/codeanticode/jogl2-tests/blob/master/src/test/windows/DialogBehindNEWT.java
Correction: the issue happens on windows (tested on 7 and 10), not Mac OS X.
So this is a simple GLWindow w/ and one unrelated AWT/Swing window/frame via the JFileChooser. We have a few one test w/ JFileChooser: TestBug1146GLContextDialogToolTipAWT. Here we bound the JFileChooser to a panel within a [J]Frame, hence we can control its presence. I would advice to do the same here, i.e. create a [J]Frame and use that as the parentComponent instead of using a NULL parent. Now you can control the containing frame as you wish. Otherwise .. I am afraid there is nothing we can do here, since the anonymous default AWT/Swing window of JFileChooser cannot be controlled and is unrelated to the NEWT GLWindow .. right? If you agree and this is acceptable for you please mark this bug as INVALID. +++ Minor notes regarding your test case: - Why not creating JOGL unit tests, so I can pull them right away into JOGL? I made a call in the forum a few weeks(?) ago. - Don't use FPSAnimator per default, only Animator benefits from vsync.
Thanks for the suggestions. If I understand correctly, I should be able to set the Frame as a parent component of the GLWindow, right? To put things in context, this needs to be used in a Processing sketch, where there is nothing but a GLWindow. The dialog Frames are only used temporarily when the user requests file or folder locations, but they are not part of a larger hierarchy. I will port the tests in my jogl2 repo as junits and create a PR. About the FPSAnimator and vsync: we call gl.glSwapInterval() https://github.com/processing/processing/blob/master/core/src/processing/opengl/PJOGL.java#L182 shouldn't be that enough to enable vsync with FPSAnimator. We use it because in Processing we have a function that allows you to set a target fps at any time during the execution of the application. Andres
(In reply to ac from comment #3) > Thanks for the suggestions. If I understand correctly, I should be able to > set the Frame as a parent component of the GLWindow, right? No, the Frame as a parent component to the JFileChooser. Then you can control that Frame. Putting a Frame somewhat as a parent to GLWindow requires you to utilize NewtCanvasAWT - a bit overkill IMHO, but possible - iff you really want to put it inside an AWT frame. I do not recommend this, since on OSX this will lead using the CALayer offscreen drawable -> worse performance etc. .. hence NewtCanvasAWT only if you must use it, or if you not intend using OSX. > > About the FPSAnimator and vsync: we call gl.glSwapInterval() > > https://github.com/processing/processing/blob/master/core/src/processing/ > opengl/PJOGL.java#L182 > > shouldn't be that enough to enable vsync with FPSAnimator. We use it because > in Processing we have a function that allows you to set a target fps at any > time during the execution of the application. NO! I have my ramblings somewhere .. forgot. FPSAnimator does not issue vsync at all, i.e. it is completely orthogonal and only schedules display commands according to the given fps value. VSync is enable per default now, via setSwapInterval(1). See <http://jogamp.org/deployment/archive/master/gluegen_895-joal_621-jogl_1447-jocl_1091/javadoc/jogl/javadoc/com/jogamp/opengl/GLBase.html#setSwapInterval%28int%29> Animator simply renders as fast as possible, or at least giving other threads a chance via Thread.yield() - thats it. VSync itself will cause the animator thread to pause while waiting for the vsync at swapBuffers()! Now .. you can adjust rendering speed w/ vsync by simply choosing frames to skip, i.e.: - Monitor @ 60hz - swap-interval 1 -> 60hz - swap-interval 2 -> 30hz - .. Only use FPSAnimator if you know .. there is no vsync possible, i.e. for offscreen drawables! > > Andres