Demo-page for our diploma-thesis (swing-components with 3D extension)

[Saxer]

Did the new pipeline-version work for you?

For the jogl part I changed nothing. I just signed one nightly-webstart from this week.

One thing I'd like to have within the GLJPanel is a manually forceReshape() method. Right now I pass the graphics-object of an 10x10 BufferedImage to the paint-method of our GLJpanels in order to reshape it more or less "directly".

Note: Corresponding to your comments, we spent a lot of work into the resizing / dynamic layout functionality of flipbox and tabbedpane.

One question about the jogl-history. Is it true, that jogl was a pure java.net-project at first and turnt into the refernce-implementation of jsr231 in late 2006? Unfortunately I can't find any documentation as well as old sources :-(.

And one question about the Texture-class which shippes with jogl: Am I right with the assumption, that it will only work with Versions of OpenGL >= 1.1 ?

[Ken Russell]

Did the new pipeline-version work for you?

Unfortunately no. I can sometimes see part of the animation, but usually there's a pause where no animation or other changes are visible, and a fair amount of garbage (like pieces of the component showing up in the wrong place).

One thing I'd like to have within the GLJPanel is a manually forceReshape() method. Right now I pass the graphics-object of an 10x10 BufferedImage to the paint-method of our GLJpanels in order to reshape it more or less "directly".

This sounds like a bad hack. Why don't you just call setSize() on the GLJPanel?

One question about the jogl-history. Is it true, that jogl was a pure java.net-project at first and turnt into the refernce-implementation of jsr231 in late 2006? Unfortunately I can't find any documentation as well as old sources :-(.

Yes, that's correct. If you go through the slides for the various presentations on the JOGL home page you should be able to piece together things a bit better. Old builds of JOGL are here. As of mid-2004 we started archiving source bundles. Note that the version numbers are a bit confusing. The last version of the pre-JSR-231 JOGL (now obsolete) was called 1.1.1. The JSR-231 sources are now almost up to a version 1.1.1 as well.

And one question about the Texture-class which shippes with jogl: Am I right with the assumption, that it will only work with Versions of OpenGL >= 1.1 ?

Yes. It used to be restricted to 1.2 and above but should now work with 1.1.

[Saxer]

Well concerning the "bad hack" and your suggested version there's a problem.

Consider the following test-case: First of all all of our calibration work is done within the reshape-callback. Use the flip-demo and fill it with lets say 10 flip's of the smallest size the slider provides. Now resize the window to fit two flips in a row. For some rows the scrollpane translates the swing-part of the flip-component virtually out of the window-bounds. There wouldn't be any problem. I'm able to position the gljpanel in the "off". However that causes a problem. It seems, that those gljpanels in the off won't get any reshape-callbacks anymore. The result: Even if the flips got scrolled into the visible part of the window we can't get them animate any more, because we get no paint-calls and therefore no reshapes. I inspected the code of the GLJPanel. Only paintComponent manages needed reshape-calls (correct me if I'm wrong with this). So the paint(image.getGraphics) was the nearest solution I could find. Of course we could do the positioning thing out of the reshape-callback but something within myself says that it's no nice solution.

We made a webstart to demonstrate: http://www.fusion-laboratory.de/demos/demo_flipbox2.jnlp
As mentioned above fill in lets say 7 flips.Resize them to the minimum. Resize the frame to the minimum. Press: "Flip all". aybe you have to scroll to the non visible flips.

Edit: Right now I'm having access to an pipeline-enabled pc. There were a lot of synchonisation problems. Never thought, that SwingUtilities.convertRectangle requires a treelock (which caused a deadlock :-(  out of our RepaintManager-implementation)

By the way: Could you tell me when you and Chris Kline began with the Jungle-project? I found the name but no additional information about it.

Games published by our own members! Check 'em out!

[Saxer]

One additional pipeline issue.

I think I resolved the size-error in the flipbox-demo with the pipeline enabled. But only by half :-( . As I mentioned we do the calibration stuff wihtin the reshape-callback. With the pipeline enabled there are a lot of reshape's as you know. So I decided to ignore all the reshapes starting at count 2. That seems to work nice for nearly every flipbox-count. Unfortunately only if I insert all of the flips before the frame is shown up.

After inserting a flip after showing up the frame seems to reset all of the projektion-settings => all of the 3D-content renders "too big".

Now there's the problem: If I follow every reshape and set the projection accordingly causes a  big performance loss. But the other solution produces too big renderings. I don't know how to decide properly if I should setup the projection again.

Edit: I used -Djogl.debug=true and found out, that every context is destroyed and new constructed. That's a really bad news for me.  The init-callback comes far to often *g* so I cant't take it as a criteria. Maybe we could introduce some kind of glcontextlistener?

Edit2: I cached the GLcontext-object and right now i check wether the object equals the return value of getcontext(). Nevertheless it ought to be an ugly hack *g*

Edit3: We updated the flipbox-demo (pipeline). It might now work (hopefully). The link from my previous post still demonstrates the reshape-problem.

[Ken Russell]

The flip-box demo is looking better, but there's still some garbage that peeks through when some kinds of repaints occur. On my machine with old drivers (which are unfortunately all that seem to run the Java 2D/OpenGL pipeline reliably) the performance of the non-pipelined version is also better than the pipelined version.

Sorry, but I don't have much advice to offer. My only suggestion is again to look at the XTrans demo in the jogl-demos workspace, which performs all of the on-screen rendering using JOGL rather than a mixture of Swing and JOGL. I get good performance and reliability with that demo on my machine. Perhaps there are some techniques you can borrow.

BTW, Chris Kline and I started the Jungle project in roughly September 2002.

[Saxer]

Well I think our setup is completely different than the xtrans-stuff. Also you doesn't seem to use any GLJPanels. Instead you're doing all of the GL-stuff directyl via Java2D.invokeWithOGLContextCurrent. I think because of the running time of our diploma-thesis a complete adaption of the xtrans-demo isn't possible (Also I don't see any possibible adaption right now instead of completely replace the repaint-behaviour).

Nevertheless thanks so far - every work needs to have a vision 

BTW: Did you get my E-Mail converning the jogl-homepage?

[Ken Russell]

BTW: Did you get my E-Mail converning the jogl-homepage?

Yes, I'll try to add your link today.