Activity for Runic
-
Runic posted a comment on discussion Developers
Well that sucks! But, That what I get for posting before testing. It sure would be nice if that did work.
-
Since using --add-opens vm options seems unclean to you . Consider modularizing the SPManager and declare the needed "opens" for reflection within it's module-info.java instead.
-
It's definitly broken and probably has been for a very long while. Looks like the author changed the IOPorts defined, but failed to finish changing the coding of it's getAverageValue method so that it would still function correctly. First It looks for COLORs to compare from IOPort 2 (labeled: Color 1) and IOPort 3 (labeled: Scaler 1: 1) But users can not attach a color to IOPort 3 as it's defined as a NUMBER not a COLOR BUT SHOULD BE using IOPort 7 not 3 if the above color compare does not return...
-
It's definitly broken and probably has been for a very long while. Looks like the author changed the IOPorts defined, but failed to finish changing the coding of it's getAverageValue method so that it would still function correctly. First It looks for COLORs to compare from IOPort 2 (labeled: Color 1) and IOPort 3 (labeled: Scaler 1: 1) But users can not attach a color to IOPort 3 as it's defined as a NUMBER not a COLOR BUT SHOULD BE using IOPort 7 not 3 if the above color compare does not return...
-
No problem, I just wanted to help keep AOI working on macs and I like to bug hunt.
-
Yes, I do. But I haven't used my github account for much of anything except to try out github, like 4 years ago. In preperation of having to commit a project into a private github for an a$$hole company that bought the company I use to work for. 100,000+ lines. Bad Memories! I might get around to it. But if you'd like to get it over there now, feel free to. Yeah I kind of figured the no quit on last window close on macs is intentional. And I prefer it to not quit, unless actually told to. Mac users...
-
I had only rendered 1 frame and did not save it. Just loop thru your objects in the scene and change all the objects with a layered texture to use a simple texture instead and then you should be able to get it to render using vector renderer
-
ok so I opened jojo's 'loader fight.aoi' scene and when I try vector renderer using the renderers default settings (as in, I did not change any of the renderers settings) I can see this error: Exception in thread "Thread-6" java.lang.NullPointerException: Cannot load from double array because "param" is null at artofillusion.texture.LayeredMapping.getAverageSpec(LayeredMapping.java:490) at artofillusion.texture.LayeredTexture.getAverageSpec(LayeredTexture.java:58) at artofillusion.vector.VectorRender$RenderAtom.bind(VectorRender.java:1679)...
-
And this appears to avoid the File->New issue with JOGL 2.4.0-rc1 -- uses swing worker to wait 1 sec and then do the dispose unmodified windows I tried lesser delays: .5 secs worked but .25 secs did not. public static void newWindow(final Scene scene) { // New windows should always be created on the event thread. numNewWindows++; SwingUtilities.invokeLater(new Runnable() { @Override public void run() { LayoutWindow fr = new LayoutWindow(scene); windows.add(fr); for (Plugin plugin: PluginRegistry.getPlugins(Plugin.class))...
-
And I can fix closeWindow(EditingWindow win) method in ArtOfIllusion.java so that AOI quits on last layout window close by replacing: if (windows.isEmpty()) quit(); with: String os = System.getProperties().getProperty("os.name").toLowerCase(); if (windows.isEmpty() || (os.startsWith("mac os") && windows.size() == 1) ) quit();
-
OK, It fails to quit on Macs when all Layout Windows have been closed because the windows array contains yet another non-layout window that is for the Mac menu bar which is never removed so windows.isEmpty() is never true on macs.
-
OK, It fails to quit on Macs when all Layout Windows have been closed because the windows array contains yet another non-layout window that is for the Mac menu bar is never removed so windows.isEmpty() is never true on macs.
-
OK, It fails to quit on Macs when all Layout Windows have been closed because the windows array contains yet another non-layout window that is for the Mac menu bar that is never removed so windows.isEmpty() is never true on macs.
-
OK, It fails to quit on Macs when all Layout Windows have been close because the windows array contains yet another non-layout window that is for the Mac menu bar that is never removed so windows.isEmpty() is never true on macs.
-
I tried using Vector and Raster renderers - on macOS Big Sur 11.6.1, openJDK 17.0.1 with a few untextured cudes in the scene. And I'm not having an issue using either of them. I'm assuming you are using AOI 3.2.0 Did you download it before 11/15/2021 or after? If before please try re-downloading the AOI 3.2.0 DMG that was update on 11/15/2021 and let us know if that makes any difference for you. Is this happening for you with a simple scene such as a few untextured cubes? And if simple cudes works...
-
I tried using Vector and Raster renderers - on macOS Big Sur 11.6.1, openJDK 17.0.1 with a few untextured cudes in the scene. And I'm not having an issue using either of them. I'm assuming you are using AOI 3.2.0 Did you download it before 11/15/2021 or after? If before please try re-downloading the AOI 3.2.0 DMG that was update on 11/15/2021 and let us know if that makes any difference for you. Is this happening for you with a simple scene such as a few untextured cubes? And if simple cudes works...
-
opps - fixed version without the && window != fr public static void newWindow(final Scene scene) { // New windows should always be created on the event thread. numNewWindows++; SwingUtilities.invokeLater(new Runnable() { @Override public void run() { // Auto close unmodified scene windows. // Use to be at the end of this run block. // Moved here (before new LayoutWindow) to avoid File->New // menu action hang issue with JOGL 2.4.0-rc1 on macs for (EditingWindow window : windows) { if (window instanceof...
-
But will they be able to see that the application is running, so that they know that they should try to force quit? Yes, the application should be visible in the Dock at the very least With all the Hangs I ran into I could see the App's Mac Menu and usually also a window. And a colorful pinwheel cursor (wait cursor) when the mouse is over either a window or the mac menu But this really depends on when/how it hangs
-
That's close to what I did - try this instead public static void newWindow(final Scene scene) { // New windows should always be created on the event thread. numNewWindows++; SwingUtilities.invokeLater(new Runnable() { @Override public void run() { // Auto close unmodified scene windows. // Use to be at the end of this run block. // Moved here (before new LayoutWindow) to avoid File->New // menu action hang issue with JOGL 2.4.0-rc1 on macs for (EditingWindow window : windows) { if (window instanceof...
-
If the application hangs, it will not matter if the new window is visible or not or even if there still the older unmodified window visible. As the user will not be able to interact with the windows or the nearly empty Mac Application menu because the application's EDT is frozen. The user only has a couple of choices once it hangs: Force Quit the frozen Unresponding Application or Reboot The easiest option to me is switch to JOGL 2.4.0-rc1 and move the auto close unmodified windows code to beginning...
-
If the application hangs, it will not matter if the new window is visible or not or even if there still the older unmodified window visible. As the user will not be able to interact with the windows or the nearly empty Mac Application menu because the application's EDT is frozen. The user only has a couple of choices once it hangs: Force Quit the frozen Unresponding Application or Reboot The easiest option to me is switch to JOGL 2.4.0-rc1 and move the auto close unmodified windows code to beginning...
-
Although: Here is what groovy has within their start up bash script: https://github.com/apache/groovy/blob/master/src/bin/startGroovy startGroovy ( ) { JAVA_VERSION="$("$JAVACMD" -version 2>&1 | awk -F '"' '/version/ {print $2}' | cut -d "_" -f1)" if [ "$(expr "$JAVA_VERSION" > "1.8.0")" ]; then [ "$GROOVY_TURN_OFF_JAVA_WARNINGS" = "true" ] && JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.annotation=ALL-UNNAMED...
-
I tried with groovy 3.0.9 and 4.0-rc1 and both appear to function - I only did a test of creating a scripted object (same one as before) I was also able to reduce the -add-opens vm options needed down to just this one when using either of these newer groovy libs: --add-opens java.base/java.net=ALL-UNNAMED not that more might be needed - but it launches ok now with just this one.
-
I tested the newWindow(Scene) code you posted with JOGL 2.4.0-rc1 and File->New menu action still hangs if a plugin calls setExtendedState(Frame.MAXIMIZED_BOTH) on Plugin.SCENE_WINDOW_CREATED message And I believe but have not tested, possibly also on Plugin.APPLICATION_STARTING message Nested Swing invoke laters is not something we should want in the code. I only did it for testing. But normally it should be frowned apon. If you have to nest invokeLaters it's a sign that there is something wrong...
-
I tested the newWindow(Scene) code you posted with JOGL 2.4.0-rc1 and New->File menu action still hangs if a plugin calls setExtendedState(Frame.MAXIMIZED_BOTH) on Plugin.SCENE_WINDOW_CREATED message And I believe but have not tested, possibly also on Plugin.APPLICATION_STARTING message Nested Swing invoke laters is not something we should want in the code. I only did it for testing. But normally it should be frowned apon. If you have to nest invokeLaters it's a sign that there is something wrong...
-
No, there does not seem to be a --add-opens <all> vm option I did find this when looking for such: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010749.html more food for thought: https://nipafx.dev/five-command-line-options-hack-java-module-system/
-
no there is not a --add-opens <all> vm option</all> I did find this when looking for such: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010749.html more food for thought: https://nipafx.dev/five-command-line-options-hack-java-module-system/
-
FYI, I also tested GLCanvas in place of GLJPanel in the DisposeTest2 and GLCanvas has the same issue, but you also have to add in a glcanvas.setSize( 100,100); to get it to hang like GLJPanel does. Without the GLCanvas.setSize you can't see the GLCanvas and there is no hang
-
strange that line 9 has no problem - since it's almost the same thing: coord.setOrigin(new Vec3(0,h/2,0))
-
stange that line 9 has no problem - since it's almost the same thing: coord.setOrigin(new Vec3(0,h/2,0))
-
and it's line 12 of that groovy script that throws the exception: coord.setOrigin(new Vec3(0,h+tiph/2,0)) but if I change line 12 to: coord.setOrigin(new Vec3(0,1.1,0)) the exception is not thrown
-
and it's line 12 of that groovy script that throws the exception: coord.setOrigin(new Vec3(0,h+tiph/2,0)) but if I changte line 12 to: coord.setOrigin(new Vec3(0,1.1,0)) the exception is not thrown
-
here is the exception the Groovy scripted object throws: java.lang.reflect.InaccessibleObjectException: Unable to make java.math.BigDecimal(java.math.BigInteger,long,int,int) accessible: module java.base does not "opens java.math" to unnamed module @15ff3e9e at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:188)...
-
here is the exception the Groovy scripted object throws: java.lang.reflect.InaccessibleObjectException: Unable to make java.math.BigDecimal(java.math.BigInteger,long,int,int) accessible: module java.base does not "opens java.math" to unnamed module @15ff3e9e at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:188)...
-
Yes it was the Groovy script from first post of: https://sourceforge.net/p/aoi/discussion/228117/thread/8b1e1e679e/?limit=25#4263 I did not investigate which line triggered the exception - but I did get to see the exception in a dialog at least. Most of the testing I did was done on an Intel Mac: macOS Big Sur 11.6.1 Mac mini Processor: 2.6 GHz Dual-Core Intel Core i5 Graphics: Intel Iris 1536MB
-
Yes it was the Groovy script from first post of: https://sourceforge.net/p/aoi/discussion/228117/thread/8b1e1e679e/?limit=25#4263 I did not investigate which line triggered the exception - but I did get to see the exception in a dialog at least. Most of the testing I did was done on an Intel Mac: macOSBig Sur 11.6.1 Mac mini Processor: 2.6 GHz Dual-Core Intel Core i5 Graphics: Intel Iris 1536MB
-
Yet another add-opens vm option which should probably be added to the Info.plist: --add-opens java.base/java.math=ALL-UNNAMED ran into needing this one when I tried a simple scripted object test
-
It seems to be related to being called from an ActionListener As I could not make the noted hangs happen until adding in the Menu ie. doing this would not hang: DisposeTest2() { NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); } But when called via a menu action it does hang and yeah, i know that really should be defined with a lower case n, since it's a method not a class: newWindowDisposeOldTest(); I didn't really notice it until after...
-
It seems to be related to being called from an ActionListener As I could not make the noted hangs happen until adding in the Menu ie. doing this would not hang: DisposeTest2() { NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); } But when called via a menu action it does hang and yeah, i know that really should be defined with a lower case n, since it's a method not a class: newWindowDisposeOldTest(); I did really notice it until after I ...
-
It seems to be related to being called from an ActionListener As I could not make the noted hangs happen until adding in the Menu ie. doing this would not hang: DisposeTest2() { NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); NewWindowDisposeOldTest(); } But when call via a menu action it does hang and yeah, i know that really should be defined with a lower case n, since it's a method not a class: newWindowDisposeOldTest(); I did really notice it until after I po...
-
Got it - DisposeTest2 hangs: using JOGL 2.4.0 /* * */ package maximizetest; import com.jogamp.opengl.awt.GLJPanel; import java.awt.Frame; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.util.ArrayList; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.SwingUtilities; import javax.swing.*; /** * * run and then select File->New * disposes previous frame with a GLJPanel * just after creating new frame with GLJPanel hangs * openJDK 17.0.1 -...
-
Got it - DisposeTest2 hangs: /* * */ package maximizetest; import com.jogamp.opengl.awt.GLJPanel; import java.awt.Frame; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.util.ArrayList; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.SwingUtilities; import javax.swing.*; /** * * run and then select File->New * disposes previous frame with a GLJPanel * just after creating new frame with GLJPanel hangs * openJDK 17.0.1 - macos Big Sur * */...
-
Here are a couple more that I can replace closeWindow(win); line with and still experience the File->New Hang win.setContent(new FormContainer(new double [] {0.0, 1.0}, new double [] {0.0, 1.0, 0.0, 0.0})); or for(int v = 0; v< win.theView.length;v++){ Component glc = ((GLCanvasDrawer)win.theView[v].getCanvasDrawer()).getGLCanvas(); GLJPanel glpanel = ((GLJPanel) glc); glpanel.destroy(); }
-
little more on File->New hang I still hit the File->New hang, if I replace the closeWindow(win); line in newWindow(Scene) with any of these next 3 lines: win.getComponent().removeAll(); win.viewsContainer.removeAll(); win.viewsContainer.getComponent().removeAll(); I also tried placing: win.setVisible(false); just before closeWindow(win); but it did not help yes I can see all the print lines in the output when I run MaximizeTest2 usually in the order of xxxx zzzz yyyy After adding f.validate(); after...
-
correction: DisposeTest does not Hang ( realized I was running the wrong class )
-
And yes this hangs too with JOGL 2.4.0 (and moving the f1.dispose(); to be before JFrame f2 = new JFrame("Second Frame"); still hangs) /* * */ package maximizetest; import com.jogamp.opengl.awt.GLJPanel; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.SwingUtilities; /** * * */ public class DisposeTest { DisposeTest() { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { JFrame f1 = new JFrame("First Frame"); GLJPanel canvas1 = new GLJPanel(); JPanel...
-
And yes this hang too with JOGL 2.4.0 (and moving the f1.dispose(); to be before JFrame f2 = new JFrame("Second Frame"); still hangs) /* * */ package maximizetest; import com.jogamp.opengl.awt.GLJPanel; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.SwingUtilities; /** * * */ public class DisposeTest { DisposeTest() { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { JFrame f1 = new JFrame("First Frame"); GLJPanel canvas1 = new GLJPanel(); JPanel...
-
I'll try out what you posted later - as it's almost Turkey Time for me Happy Thanksgiving
-
this MaximizeTest2 with JOGL 2.4.0 libs hangs: (and I don't see the window at all) /* * */ package maximizetest; import com.jogamp.opengl.awt.GLJPanel; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.SwingUtilities; /** * * */ public class MaximizeTest2 { JFrame f; GLJPanel canvas; JPanel p; public MaximizeTest2() { newWindow(); } public void newWindow() { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { f = new JFrame("test frame maximized both ");...
-
if that window is closed just after creating yet another layoutwindow with GLJPanel(s) but not if the previous window is closed before, instead of after
-
MaximizeTest, with JOGL 2.4.0, that's had the f.setExtendedState(JFrame.MAXIMIZE_BOTH) and f.isVisible(true) moved to be above new GLJPanel: Yes in this case, it still hangs if I comment out: p.add(canvas); File->New and disable OpenGL: the quick answers is Yes & No, but it's really No If i open AOI and OpenGL was enabled on launch and you turn it off and then do File->New it still hangs (becuase the window already open was opened with OpenGL enabled) Quit (with openGL disabled ) and relaunch and...
-
ok so If I move the for loop code in newWindow(Scene) that closes unmodified windows from the end of the run loop to the beginning of that run loop and adjust int i= the File->New hang doesn't happen for (int i = windows.size()-1; i >= 0; i--) if (windows.get(i) instanceof LayoutWindow) { LayoutWindow win = (LayoutWindow) windows.get(i); if (win.getScene().getName() == null && !win.isModified()) closeWindow(win); } it's a little flashy though, as the old unmodified window disappears before the new...
-
I can also close the initial window manually and use key commands to reopen a new without issue with the dispose() line in it's place ie. the initial window is closed already so newWindow(Scene) does not have to try and close the older window
-
also if I just commment out the last few lines in newWindow(Scene) of ArtOfIllusion that calls close window on unmodified LayoutWindows And Application Quit doesn't seem to have any issues closing the windows
-
ok so your probably not going to like this one: this is with the JOGL 2.4.0 libs debugging File->New , I can get all the way to line: dispose(); in method confirmClose() of LayoutWindow.java This is after the New window has been created and AOI is disposing of the previous unmodified LayoutWindow And commenting out the line: dispose(); in method confirmClose() of LayoutWindow.java does stop File->New from hanging
-
ARG, ok well no hang on launch anyways, but File -> New still hangs even if I remove all test frames and just have either TT or Maximize.groovy installed
-
However - I bet if I make a plugin that made a new frame that's maximized and shown - on APP Launch message - this would be prior to GLJPanel and might cause the hang
-
In short there is still some issue there when frames are maximized_both and shown just before GLJPanel is created. but I believe you should proceed with upgrading JOGL as AOI does not normally have another frame being used this way prior to GLJPanel use
-
In short there is still some issue there when frames are maximized_both and shown just before GLJPanel is created. but I believe you should proceed with upgrading JLOG as AOI does not normally have another frame being used this way prior to GLJPanel use
-
ok - so it seem 2.4.0 libs do help - in AOI code if I remove the before test frame, but leaving the after test frame and TT' maximize it seem ok and does not hang if I change the MaximizeTest code so the frame state is set to MAXIMIZED_BOTH and isVisible(true) right after the new JFrame call and before the new GLJPanel etc Then MaximizeTest also hangs with the new libs
-
not quite there yet: I think that last test passed because GLJPanel was not created after removing the code I had added to GLCanvasDrawer that hang reappeared
-
not quite there yet: I think that last test passed becuase GLJPanel was not created after removing the code I had added to GLCanvasDrawer that hang reappeared
-
not quite there yet: I thing tht last test passed becuase GLJPanel was not created after removing the code I had added to GLCanvasDrawer that hang reappeared
-
quite there yet: I thing tht last test passed becuase GLJPanel was not created after removing the code I had added to GLCanvasDrawer that hang reappeared
-
The 2.4.0 libs also fix AOI so that TT maximize works again and the test frames I was adding also work as expected. on a side note: this also made the code I had added to GLCanvasDrawer throw an exception java.lang.Error: Cannot call invokeAndWait from the event dispatcher thread ( which I was wondering why It didn't throw this exception- when I added it - and just said to myself - well we are not on the EDT for some reason even thought it should have been )
-
The 2.4.0 libs also fix AOI so that TT maximize works again and the test frames I was adding also work as expected. on a side note: this also made the code I had added to GLCanvasDrawer throw an exception java.lang.Error: Cannot call invokeAndWait from the event dispatcher thread ( which I was wondering why It didn't throw this exception- when I added it - and just said to myself - well we not on the EDT for some reason even thought it should have been )
-
The 2.4.0 libs also fix AOI so that TT maximize works again and the test frames I was adding also work as expected. on a side note: this also made the code I had added to GLCanvasDrawer throw and exception java.lang.Error: Cannot call invokeAndWait from the event dispatcher thread ( which I was wondering why I didn't throw this exception- when I added it - and just said to myself - well we not on the EDT for some reason even thought it should have been )
-
those 2.4.0 libs appear to be working for MaximizeTest code - no hang :) note I was also able to get the MazimizeTest to work with the older libs by hiding the canvas before showing the frame but I had to wait 10 or more secends before showing the canvas afterwards or it would still hang ie. had to wait until after the window was shown and had finished it's animated scaling to size
-
ok from what I can find: -XstartOnFirstThread implementation, the AWT loader supposes that it is working in the embedded mode and does not start it's own runLoop, waiting for SWT to start it. and On OS X, specifying -XstartOnFirstThread, has an effect that the AWT loader waits (on a conditional variable) until someone (supposedly SWT) starts the run loop which I got the above from https://bugs.openjdk.java.net/browse/JDK-8019496 I don't think AOI makes use of SWT or anything of the like. So adding...
-
this hangs: package maximizetest; import com.jogamp.opengl.awt.GLJPanel; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.SwingUtilities; /** * * */ public class MaximizeTest { public MaximizeTest() { } public static void newWindow() { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { JFrame f = new JFrame("test frame maximized both "); GLJPanel canvas = new GLJPanel(); // interesting - if I don't setContentPane to the GLJPanel // the HANG doesn't happen...
-
The test frames I was adding before and after new LayoutWindow kind of prove any frame.setExtendedState(Frame.MAXIMIZE_BOTH) near the moment of new GLCanvasDrawer creation would trigger this issue. But to answer your question: Yes placing Maximize.groovy in startup scripts does cause the same Hang Unless the GLCanvasDrawer constructor change i posted is applied.
-
The test frames I was adding before and after new LayoutWindow kind of prove any frame.setExtendedState(Frame.MAXIMIZE_BOTH) near the moment of new GLCanvasDrawer creation would trigger this issue. But to answer your question: Yes placing Maximize.groovy in startup scripts does to cause the same Hang Unless the GLCanvasDrawer constructor change i posted is applied.
-
Technically this is still a nested SwingUtilities.invoke as new LayoutWindow happens within an invokeLater which eventually calls new GLCanvasDrawer. Also note that I used a invokeAndWait in GLCanvasDrawer, if a invokeLater was used there. Then you would also have to deal with the canvas being null for a moment. Which would lead you to making changes elsewhere.
-
Technically this is still a nested SwingUtitlities.invoke as new LayoutWindow happens within an invokeLater which eventually calls new GLCanvasDrawer. Also note that I used a invokeAndWait in GLCanvasDrawer, if a invokeLater was used there. Then you would also have to deal with the canvas being null for a moment. Which would lead you to making changes elsewhere.
-
this change to GLCanvasDrawer.java constructor seems to FIX TT's maximize and the other test frames setExtendedState I was doing public GLCanvasDrawer(ViewerCanvas view) { this.view = view; try { SwingUtilities.invokeAndWait(new Runnable() { public void run() { GLCapabilities caps = new GLCapabilities(GLProfile.get(GLProfile.GL2)); canvas = new GLJPanel(caps); canvas.addGLEventListener(new CanvasListener()); }}); } catch (InterruptedException ex) { Logger.getLogger(GLCanvasDrawer.class.getName()).log(Level.SEVERE,...
-
nope I take that back canvas = new GLJPanel(); without the lines GLCapabilities caps = new GLCapabilities(GLProfile.get(GLProfile.GL2)); canvas = new GLJPanel(caps); still causes the hang
-
ok, so I tracked this issue further down to into ViewerCanvas constructor. And then thought of trying to disable "Use OpenGL for Interactive Rendering" via AOI preferences. And doing so TT's maximize functions as expected. further testing with those frames before and after new LayoutWindow also function as expected when "Use OpenGL for Interactive Rendering" is disabled.
-
looks like the trail ends in AOI's codebase, @ the GLProfile.get(GLProfile.GL2) call in GLCanvasDrawer.java or new GLCapabilities(GLProfile.get(GLProfile.GL2));
-
ok, so I tracked this issue further down to into ViewerCanvas constructor. And then though of trying to disable "Use OpenGL for Interactive Rendering" via AOI preferences. And doing so TT's maximize functions as expected. further testing with those frames before and after new LayoutWindow also function as expected when "Use OpenGL for Interactive Rendering" is disabled.
-
ok, so I tracked this issue further down to into ViewerCanvas constructor. And then though of trying to disable OpenGL via AOI preferences. And doing so TT's maximize functions as expected. further testing with those frames before and after new LayoutWindow also function as expected when OpenGL is disabled.
-
I disabled "Animate automatic moves" preference option and re-enabled TT's maximize. File -> New and it freezes or File -> Quit and Launch Again and it freezes disabled TT maximize in it preference file and it no longer freeze
-
I see no such preference in AOI
-
SwingTest.java works fine - as I suspected it would. In my basic test class I create frames and setExtendedState(BOTH) using Frame, JFrame and BFrame both inside and outside of invokeLaters and looped it to create and maximize 100 windows back to back and this worked fine too.
-
from TT's Manifest: Created-By: 1.7.0_45 (Oracle Corporation)
-
I've already tried recreating a basic java class to attempt to reproduce this issue. Without the new LayoutWindow in the mix I could not reproduce the issue. But I can give this class a try too. Might be a while before I get to it though
-
but that running on a window that been open for a moment already - so kind of delayed
-
That worked fine, even maximized the window - I could tell because LayoutWindow is normally 11 pixels short on macos due to code in LayooutWindow about some unknown mac bug from the past
-
That work fine, even maximized the window - I could tell because LayoutWindow is normally 11 pixels short on macos due to code in LayooutWindow about some unknown mac bug from the past
-
Yes the Frame(s) placed before and/or after new LayoutWindow coding (really just the before was enough) and setting their state to BOTH would cause the same hang that TT's maximize does. And Yes that was just setting Extended State on those other frames without even touching layoutwindows.setExtendedState And Yes, that was without TT installed or any of the additional plugins
-
And In case you missed it wrapping plugin.processMessage(Plugin.SCENE_WINDOW_CREATED, new Object [] {fr}); in another invokeLater fails to fix TT's maximize I built an test plugin to mimic TT maximize and in that case I had to wrap the layoutwindow.setMaximized(true) call within the plugin in an invokeLater runnable to get it to work
-
I had also tested placing a new JFrame and setting it's state at several locations previous to the call to newWindow() in ArtOfIllusion.java and I could get it to function without hang if placed anywhere before runStartupScripts() but not after. So I had commented out runStartupScripts and it still failed. so it seemed the closer I placed the test frame code to LayoutWindow's creation. Was when the HANG issue would appear. Commenting out the new LayoutWindow, etc. temporarly made the HANG issue disappear....
-
Yes the Frame(s) placed before and/or after new LayoutWindow coding (really just the before was enough) would cause the same hang that TT's maximize does. And Yes that was just setting Extended State on those other frames without even touching layoutwindows.setExtendedState And Yes, that was without TT installed or any of the additional plugins
-
delayed slightly by wrapping the setExtendedState calls in invokeLater runnables
-
I did tests without bit-wise-ORs that caused the hang too. And with BFrame, Frame or JFrame not just LayoutWindow, but layoutWindow needed to be in the mix for the issue to happen. Tis why I became even more courious to find the cause, which I still have not. At this point I would have to start disabling parts of layoutwindow to see if I could learn more sbout what is triggering this.
-
I did tests without bit-wise-ORs that caused the hang too. And with BFrame, Frame or JFrame not just LayoutWindow, but layoutWIndow need to be in the mix for the issue to happen. Tis why I became even more courious to find the cause, which I still have not. At this point I would have to start disabling parts of layoutwindow to see if I could learn more sbout what is triggering this.
-
I think this is more of a JDK issue and possibly not really an issue with AOI/Buoy code at all.
-
And Delaying the calls to setExtendedState seems to bypass the issue
-
I think this is more of a JDK issue and possibly not really an issue with AOI/Bouy code at all.
-
getExtendedState was returning 0 prior to plugin trying to change state, when I tested such
-
ah, ok this vm option is to ensure the main() method is run on the first AppKit thread when adding this to Info.plist of a installed from dmg AOI 3.2 : <key>StartOnMainThread</key> <string>true</string> AOI just bounces in the dock for a good long time but never launches and shows as not responding if dock icon is clicked; no menu; no window
1 >
