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

OpenGL Development JOGL Development
#21

@Ken: We’re using the “http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp” for the jogl distribution. I couldn’t reproduce the pipeline-bug of flipbox on a local maschine. Even with the latest nightly builds all the output is okay. Is there a jnlp out there with the current nightly’s?

Edit: I found the webstart-nightly.zip on the jogl home page. We copied the jogl.jnlp and modified it for us. Unfortunately we get nothing but jnlp syntax errors… all we did was just replacing the paths.

Edit2: I tested it again (on another server). It seems those webstart jars (nightly) are not signed. Therefore the native-libs can’t be installed via webstart. I haven’t played around with this JNLPAppletJoglLauncher-stuff. Or should I?

Thanks
Klemens

#22

Correct, the nightly builds are not signed. This is deliberate; we want to test a given build before certifying it. There aren’t significant differences between the nightly builds and 1.1.1-rc3.

Out of curiosity, what machine are you running on where the Java 2D / OpenGL pipeline and your framework runs successfully? I found that things are unfortunately pretty broken with NVidia hardware and the 93.71 and 162 drivers. My notebook with 81.85 drivers runs the Java 2D / OpenGL pipeline but exhibits the sizing bug with the flipbox, etc.

#23

[quote]There aren’t significant differences between the nightly builds and 1.1.1-rc3.
[/quote]
I tested with the nightly-build locally and can’t reproduce it :-(. May I send you an executeable jar file? Maybe you can confirm the “fixed” bug with the nightly builds on you laptop. If possible could you give a signed webstart version to me (if it’s legally ok)?

My “pipeline test maschine” is an ATI mobile board (M200 or X200 - don’t remember the name really). Those drivers seem to be quite ok. Nevertheless the board itself is quite slow. But with the pipeline I usually get quite performant results.

As you remember I once wrote about my 8800 GTS. I wrote to the nvidia forums as well to this vista bug form thing. Unfortunately I couldn’t achieve a nvidia developer account.

I think you are closer to the nvidia guys aren’t you? Unfortunately they seem to be very busy with the hole “vista thing” and have no open ears for our java-jogl problems :frowning:

#24

I’ll be on vacation all this week and won’t be able to test your binaries or do a release. My advice would be to see if a friend has a pre-8000 series NVidia card that you can try to get the Java 2D / OpenGL pipeline working on, and try your code there.

We at Sun do have some contacts at NVidia, and are renewing the discussion around their driver reliability due to the recent breakage of the Java 2D / OpenGL pipeline.

#25

For those of you who couldn’t get the demo-apps working. I’ve uploaded 4 videos to youtube.

Here’s the link to the profile: http://www.youtube.com/profile?user=FusionLaboratory

Especially any kind of comment is highly recommend.

Thanks
Klemens

#26

Hmmm, that youtube link is badly placed on your web page; you can (a) embed the video on your page, or (b) place a play_video
http://www.fusion-laboratory.de/images/movie_run.jpg
 link.

#27

the kitchen demo (piped & non-pipe enabled) app works like a charm on my pc:
AMD 2800+, 512Mb RAM, nVidia 7600GS (AGP slot), java 1.5.0_12

maybe java 6 is to blame?

#28

Ok, I’m getting the wrong image during the flip for the “Flip-Box”, and it should be defaulted at 0.4 seconds, or maybe less! The “Kitchen Demo” was excellent!

Using Java 6 and standard mode for the Kitchen Demo

#29

Right now we fixed at least the FlipBox-Demo bugs. We introduced a self-signed jogl nightly build version for FlipBox’s pipeline-version (only for that). Currently only the Windows x68 stuff is signed for that nightly. I’ll update to more platforms as soon I get the time.

#30

Did you have to make any changes to JOGL? Is there anything you would like us to check in to the main JOGL tree?

#31

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 ?

#32

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).

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

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.

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

#33

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 :frowning: 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.

#34

One additional pipeline issue.

I think I resolved the size-error in the flipbox-demo with the pipeline enabled. But only by half :frowning: . 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. ;D 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.

#35

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.

#36

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 ;D

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

#37

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