if (openglImage != null) { g.drawImage(openglImage, sp, getHeight() - openglImage.getHeight() - sp, null); }1) This normal java 2D software rendering .Why two javaImage and openglImage required when both are draw using drawImage?.2) How GLJPanel will enable openGL image rendering ?I looked at paintComponent but didn't get much information.3) I commented the paintComponent of GLJPanel but still able to draw the image ?Just wanted to know how openGL accelartion is performed ?

Let's hope this is the right forum to talk about what following. Sorry otherwise.

I want to talk about the XTrans demo of jogl. First thank you for the person who did it ... but there's no his/her name in the code so she/he stays anonymous . It is a great demo for me and probably need to be advertized on JavaDesktop. Anyway, there's no name but no copyright as well ... and I would really like to re-use this code. My goal is to re-write a "rotatable" windows manager called DiamondSpin. You can see screenshot / video of a previous version here : http://www.merl.com/projects/diamondspin/

jogl-java2D bridge looks a much cleaner solution similar to Agile 2D (http://agile2d.sourceforge.net/) but probably with a better support and a more promizing future.

If you looked at the video my question is : when I'll have a rotated JMenu or JComboBox what will happen to the corresponding popup ? Is it possible to intercept the popup ? If it's a LW component I guess yes but what's going to be the wrapper (OffscreenComponentWrapper) for this new component ?

Again this is a very impressive demo and I would be glad to know the author to thank him/her in person. Regards, fred = frederic.vernier('at')limsi.fr

\I want to talk about the XTrans demo of jogl. First thank you for the person who did it ... but there's no his/her name in the code so she/he stays anonymous . It is a great demo for me and probably need to be advertized on JavaDesktop. Anyway, there's no name but no copyright as well ... and I would really like to re-use this code.

You're welcome -- sorry for the lack of copyright / attribution in the code. I've added a copyright notice and author attribution (I'm the author of the demo). It's covered under the BSD license, same as JOGL.

jogl-java2D bridge looks a much cleaner solution similar to Agile 2D (http://agile2d.sourceforge.net/) but probably with a better support and a more promizing future.

I'm personally excited about the bridge and about the new functionality it enables. It is still very experimental but I think that some sort of interoperability mechanism will continue to exist regardless of the APIs involved. The XTrans demo was really built just to show that there are other new effects enabled by the bridge that are not obvious just by a quick inspection of the APIs.

Quote

If you looked at the video my question is : when I'll have a rotated JMenu or JComboBox what will happen to the corresponding popup ? Is it possible to intercept the popup ? If it's a LW component I guess yes but what's going to be the wrapper (OffscreenComponentWrapper) for this new component ?

Good question. I don't know where those popups are placed in the component hierarchy but based on experiences with tooltips they definitely will not show up in the correct place. The XTrans demo has several shortcomings in its current form:

There are repainting-level bugs where the "back buffer" for the components isn't preserved correctly all of the time. This needs to be fixed by adding a "lock"/"unlock" primitive to regions of the back buffer so that while a component is being animated for closing the corresponding portion of the back buffer isn't destroyed.

Tooltips, popups, etc. aren't handled correctly.

Repaint requests must originate from the OffscreenDesktopPane / XTDesktopPane or higher. If a repaint request begins from further down the widget hierarchy the OffscreenComponentWrapper doesn't really do what it's intended to do. I think this has to be fixed by installing an OffscreenRepaintManager which propagates all repaint requests up the widget hierarchy to any containing OffscreenDesktopPane though I tried to avoid this in the current demo. Knowing the current limitations though I think this would have to be done.

There is no transformation of mouse events, so while a component is being animated (or if it is rotated, translated from where it should be, etc.) mouse interaction will not work properly.

I've talked with the Looking Glass 3D team about this demo and their work and it's my understanding that they are in the process of building a 3D-aware set of peers for Swing components which allows those components to be arbitrarily transformed in 3D. The XTrans demo, in comparison, simply redirects the graphics rendering for these components offscreen and enables compositing of those results. The two techniques are similar in some ways but quite different in others. I think that if you are aiming to get 100% correct behavior while transforming widgets you might want to look into implementing a Toolkit with the necessary peers to make Swing work. The transformation of events to work within the XTrans framework probably isn't all that difficult, but since there are other issues like the tooltip / popup problem, it might be better to start with a more complete solution.

Just tried Twinkle with Mustang b66. It's broken (showing the wrong photo sometimes) and it's unusably slow . I saw the movie deom on his blog.. and I see nothing like that.. there is no smooth animation - just a couple chunky changes and the images are left in the wrong locations etc.

I was testing on Windows, and I recall reading something about needing to disable the DirectDraw pipeline.. but I question whether that can be done via Web Start (if it can't be done via Web Start then that's another big Web Start "bug").

It was the same for me in terms of the time between frames... it was measured in seconds and the end result was simply wrong anyway. I suspect it is a deployment issue - but obviously a serious one.

I wrote this demo and it works just perfectly on various Mustang builds on my computer so I have to admit I have no idea of what's going wrong in your case. Could you try to download the source achives and use this command to run the demo: java -classpath bin -Dtwinkle.aa=true -Dsun.java2d.opengl=True -Djogl.debug.Java2D org.progx.twinkle.Twinkle

If you still have very bad performance, try to turn -Dtwinkle.aa=true to -Dtwinkle.aa=false

I had MANY problems with the OpenGL pipeline on my previous computer which had an ATI graphics card. I now run with an nVidia and I have seen none of the bugs I experienced before (mainly corrupted pictures).

I am using nVidia so I was a little suprised that it was so slow. I will give it a try tonight.

I think there were some issues with nvidia drivers and the Java2D OpenGL pipeline which you may be running into.Some of those issues were fixed with the latest drivers, you might want to trythem if you haven't already.

I downloaded the latest nVidia driver and it is still no good. No AA doesn't help either. Setting noddraw to true seemed to help just a little bit but it is still really slow. I will put it through the netbean profiler and see if anything sticks out.

After that I get the same experience. Clicking the arrows results in the first image blinking away. The next image does not slide into place. No further exceptions are reported. With Twinkle.aa=false I just got the exception once, but the end result was the same.I'm running Win XP pro SP2, 1GB RAM, dual 2.4 GHz Xeon, GeForce4 Ti 4200 using nVidia drivers 81.85

This is a bug in NVidia's recent OpenGL drivers on Windows which apparently slipped through the cracks because they didn't run the Java2D/OpenGL regression test suite which Chris Campbell provided to them on that platform. From what I've heard it will be fixed in their next driver release.

This is a bug in NVidia's recent OpenGL drivers on Windows which apparently slipped through the cracks because they didn't run the Java2D/OpenGL regression test suite which Chris Campbell provided to them on that platform. From what I've heard it will be fixed in their next driver release.

I'm, back at work now and I can't reproduce the crash. I must have made a mistake earlier. The Twinkle application still looks horrible and rendering is obviously hosed, but when I exit I'm not getting the crash in the nVidia code anymore so I have to conclude that the crash IS fixed in 81.98.

Thanks for posting the links again. I profiled Twinkle and there doesn't appear to be anything out of the ordinary. GLUtilities.renderAntiAlaised and gl.glbegin take upthe most time but that would seem to be expected. I am going to see poke around with other GLJPanel apps and see if they are also really slow.

The first one is it crashes when I exit as soon as I activate the flag -Dsun.java2d.opengl=trueI've read it may come from the nvidia driver and I do weird things with my nvidia driver (I've installeda GeForce forceware82.10 driver on a Quadro FXGo700 to enhance perfs) so I'll have to test on a cleancomputer before I can complain ;-)

The second one is an incompatibility question between the flag -Dsun.java2d.opengl=true and -Dopengl.1thread=awtwhen I activate -Dopengl.1thread=awt my openGL functions init(), display()... are called by the awt event thread Thread.currentThread() in display() returns: [AWT-EventQueue-0,6,main] (so it works)

When I activate no flag the default behavior is Thread.currentThread() in display() returns: [JOGL GLWorkerThread,6,main]

But finally when I actiate the 2 flags together (my live is full new experiences ;-) I getThread.currentThread() in display() returns: [Java2D Queue Flusher,10,main]

Which is bad for me because going though the thread [AWT-EventQueue-0,6,main] allowed me to get rid of a poor deadlock in my code

with -Dsun.java2d.opengl=true I have all the speed I ever dreamed on a GLJPanel ... but I really liked the awt thread stuff. On the other hand I wonder if I don't miss something about the whole threading issue

If someone has an insight on the problem to share, I would be very gratefull

I have the newest JOGL and Java 6 beta yet I get very low frame rates with this code. Could someone point out the error of my ways? The same code runs very fast when the AWT widget is used in place of the Swing.

hi.. i am getting error for import javax.media.opengl statement. I have downloaded jogl.jar file but it dont show javax.media.opengl pckg.Can please help me in this case. This is my first exp of doing programming with the JOGL. Please help me...

Excellent question. I'm pleased to be able to tell you that as of the day before yesterday (literally) the Java2D/JOGL bridge is working on Mac OS X thanks to help from Gerard Ziemski at Apple (and also Chris Campbell from Sun who helped Apple get the Java2D/OpenGL pipeline running on OS X). The new functionality will be present in the Developer Preview 5 of Mustang on OS X. There is a remaining problem on the JOGL side with GLPbuffers when the bridge is enabled, but I'll need bits to test with before I can fix that problem.

I tried some GLJPanel stuff this past weekend with the latest Java 1.6 beta and it was significantly slower than Java 1.5. Unfortunately, I will not be able to enable the opengl pipeline, so I'm using the default pbuffer solution. I would expect, though, that 1.6 would be at least as fast as 1.5 even with the old renderer. But on my ThinkPad T41 laptop on WindowsXP running the JCanyon demo (modified to use the Swing renderer), I get 8-9fps with Java 1.5, and 3-4fps with Java 1.6. I think I'm using the latest betas of everything and the latest drivers available for my laptop.

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