- maximizing the window does not resize the canvas, although resizing the window usually does. The result is the figures are cropped to their previous window size and ocassionally there is junk in the rest of the window. I also see some occasional shards during resize. It's as if the adjusted viewport sometimes lags behind the window changes.

- The application hangs. I can't find a simple trigger, but resizing, rotating, maximizing, restoring to the previous size when repeated for a while (10 seconds to a few minutes) cause a hang. Here's a thread dump:

I find this application exhibits two of the resize problems I've seen in my own application, at least on a Mac 1.33Ghz 17" Powerbook.

I have a suspicion the problem lies in the JOGL arithmetic in determining the upper left screen coordinates, where they are allowed to extend outside of the canvas.

1. It looks like the repaint after a resize is delayed behind the window event - as if the previously reported size as the window continuously repaints during the drag of a corner is what is displayed when the drag completes. So if the window is expanding, there is white space or garbage at the right and bottom edges. If it is decreasing, the view may be cropped to something larger.

2. If I resize, at least on the Mac, I can move the bottom of the window up into the menu area, causing the following:

This will probably be of little help, but with the nightly build from 10/17, I get a window, then:

Quote

Using ATI workaround of dispatching display() on event threadjava.lang.IllegalMonitorStateException: current thread not owner at net.java.games.jogl.impl.JAWT_DrawingSurface.Unlock0(Native Method) at net.java.games.jogl.impl.JAWT_DrawingSurface.Unlock(JAWT_DrawingSurface.java:61) at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.unlockSurface(MacOSXOnscreenGLContext.java:253) at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.free(MacOSXOnscreenGLContext.java:161) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:319) at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.invokeGL(MacOSXOnscreenGLContext.java:84) at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208) at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75) at MyAnimator$1.run(AnimatorTest.java:113) at java.lang.Thread.run(Thread.java:552)Bus error

Since Ken Russell requested problems also be discussed on this thread, the big show stopper for me is the reshape problem which causes system hangs. It's been discussed quite often, most recently on the java-seed@lists.apple.com list under the topic:

> What version are you using? If its not the latest nightly build or the latest release build from the site, then you need to upgrade.

Checking the cvs repository (:pserver:xxx@cvs.dev.java.net:/cvs jogl) on a fairly regular basis, I've seen no changes at all in the source code for months (weeks if you count a change on 1/31 that went in and back out because of my confusion). Same for the source distribution on the nightly build site <https://games-binaries.dev.java.net/build/index.html>. And I find no release builds there either. Are the nightly builds done off something else? Am I looking in the right places?

I'm not complaining, just making sure I understand the current code state.

As I mentioned in an earlier post, there seem to be problems with GLCanvas and AWT or Swing - even in an independent windows - on a Win2K system.

I've posted a simple modification to the Gears demo that instantiates a Swing Slider in another window to control the rotation of the gears. There are Java Web Start files to run it requesting either double or single buffered GL capabilities.

Don't run it on a system you don't want to crash. It's behavior is not repeatable.

I can run it and it looks normal for a few times, but resizing the GL window can hang the PC. Sometimes I get a blank screen, sometme the performance is slow, sometimes everything looks fine. But repeated execution of the same application gives unpredictable results.

I've been having little luck in using a Swing control in one window to manipulate a scene in a different GL window. I'm trying this to avoid some of the issues mentioned on this group in mixing the two in the same Frame.

I see two problems -

1 - poor performance on OS X, very poor on Win2K. The awt thread does not seem to take much cpu time, but it seems like the repaint of the GLCanvas takes a long long time. Direct manipulation through a mouse in the GL window itself is instantaneous, as is the manipulation of the control by itself.

2 - lack of anything displayed at all on Win2K or XP when there is much object complexity. Once I saw the the GL canvas come alive afer 2-3 minutes when the objects were the three gears from the Gears demo.

The first problem A is shown in a modified form of the example in this thread and posted at:

The problem with the lack of any display seems to happen both with an Animator running freely and when repaint is used. I'll put an example of that up when I get time. I've set the doubleBuffer capability to false on the PC with no effect.

I'd like to find some way to get this working. Any pointers to parts of jogl to look at would be appreciated. Working demos that use both Swing and jogl and which run well would be even better.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org