dvgarun
Senior Newbie 
|
 |
«
Reply #30 - Posted
2005-11-24 09:13:19 » |
|
I am very new to this JOGL . in JGears.java if (javaImage != null) { g.drawImage(javaImage, sp, getHeight() - javaImage.getHeight() - sp, null);
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 ?
|
|
|
|
vernier
Senior Newbie 
Java rock!
|
 |
«
Reply #31 - Posted
2005-11-27 17:49:23 » |
|
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
|
|
|
|
Ken Russell
|
 |
«
Reply #32 - Posted
2005-11-28 01:27:16 » |
|
\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. 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. 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.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
swpalmer
|
 |
«
Reply #34 - Posted
2006-01-10 23:05:26 » |
|
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. Are others seeing this?
|
|
|
|
GKW
|
 |
«
Reply #35 - Posted
2006-01-10 23:38:18 » |
|
I'm using b60 and it is slow. By slow I mean seconds between frame updates.
|
|
|
|
swpalmer
|
 |
«
Reply #36 - Posted
2006-01-11 13:36:46 » |
|
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.
|
|
|
|
Gfx
Junior Newbie
|
 |
«
Reply #37 - Posted
2006-01-11 18:57:48 » |
|
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).
|
|
|
|
GKW
|
 |
«
Reply #38 - Posted
2006-01-11 20:59:48 » |
|
I am using nVidia so I was a little suprised that it was so slow. I will give it a try tonight.
|
|
|
|
trembovetski
|
 |
«
Reply #39 - Posted
2006-01-11 23:48:54 » |
|
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 try them if you haven't already. Dmitri
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Gfx
Junior Newbie
|
 |
«
Reply #40 - Posted
2006-01-12 07:54:46 » |
|
I need to add my computer is a P4 1.8 Ghz laptop with 1 GB of RAM. So it's pretty good but it's not extremly powerful.
|
|
|
|
GKW
|
 |
«
Reply #41 - Posted
2006-01-12 19:48:43 » |
|
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.
|
|
|
|
swpalmer
|
 |
«
Reply #42 - Posted
2006-01-12 20:36:49 » |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
| D:\DevJava\Twinkle>java -classpath bin;lib\vecmath.jar;..\JOGL\jogl.jar -Dtwinkle.aa=true -Dsun.java2d.opengl=True -Djogl.debug.Java2D org.progx.twinkle.Twinkle OpenGL pipeline enabled for default config on screen 0 JOGL/Java2D integration enabled exception in QueueFlusher: java.lang.NullPointerException at org.progx.jogl.rendering.ReflectedQuad.render(ReflectedQuad.java:37) at org.progx.twinkle.ui.PictureViewer.setAndRender(PictureViewer.java:604) at org.progx.twinkle.ui.PictureViewer.renderItems(PictureViewer.java:584) at org.progx.twinkle.ui.PictureViewer.access$22(PictureViewer.java:582) at org.progx.twinkle.ui.PictureViewer$3.render(PictureViewer.java:532) at org.progx.jogl.GLUtilities.renderAntiAliased(GLUtilities.java:89) at org.progx.twinkle.ui.PictureViewer.render3DScene(PictureViewer.java:540) at org.progx.jogl.CompositeGLPanel.display(CompositeGLPanel.java:73) at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:77) at javax.media.opengl.GLJPanel$Updater.display(GLJPanel.java:708) at javax.media.opengl.GLJPanel$DisplayAction.run(GLJPanel.java:863) at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:128) at javax.media.opengl.GLJPanel$1.run(GLJPanel.java:349) at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(Unknown Source) exception in QueueFlusher: java.lang.NullPointerException at org.progx.jogl.rendering.ReflectedQuad.render(ReflectedQuad.java:37) at org.progx.twinkle.ui.PictureViewer.setAndRender(PictureViewer.java:604) at org.progx.twinkle.ui.PictureViewer.renderItems(PictureViewer.java:584) at org.progx.twinkle.ui.PictureViewer.access$22(PictureViewer.java:582) at org.progx.twinkle.ui.PictureViewer$3.render(PictureViewer.java:532) at org.progx.jogl.GLUtilities.renderAntiAliased(GLUtilities.java:89) at org.progx.twinkle.ui.PictureViewer.render3DScene(PictureViewer.java:540) at org.progx.jogl.CompositeGLPanel.display(CompositeGLPanel.java:73) at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:77) at javax.media.opengl.GLJPanel$Updater.display(GLJPanel.java:708) at javax.media.opengl.GLJPanel$DisplayAction.run(GLJPanel.java:863) at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:128) at javax.media.opengl.GLJPanel$1.run(GLJPanel.java:349) at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(Unknown Source) |
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 I'm now downloading nVidia drivers v 81.98
|
|
|
|
swpalmer
|
 |
«
Reply #43 - Posted
2006-01-12 20:43:49 » |
|
Exiting crashes in native code related to OpenGL. See attached error log.
|
|
|
|
Ken Russell
|
 |
«
Reply #44 - Posted
2006-01-13 02:07:41 » |
|
Exiting crashes in native code related to OpenGL. See attached error log.
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.
|
|
|
|
campbell
Junior Devvie  
Java games rock!
|
 |
«
Reply #45 - Posted
2006-01-14 21:47:03 » |
|
Exiting crashes in native code related to OpenGL. See attached error log.
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. Hey Scott, See this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6341149As Ken mentioned, this was a regression in Nvidia's 81.85 driver release for Windows, and they quickly fixed it in 81.94. Are your drivers up to date? Thanks, Chris
|
|
|
|
swpalmer
|
 |
«
Reply #46 - Posted
2006-01-14 23:56:33 » |
|
I mentioned above, I've upgraded to 81.98 and have the same problem.
|
|
|
|
campbell
Junior Devvie  
Java games rock!
|
 |
«
Reply #47 - Posted
2006-01-15 20:02:56 » |
|
I mentioned above, I've upgraded to 81.98 and have the same problem.
Sorry, I was tuning in and out. Is this crash-on-exit reproducible with non-JOGL apps, like just running SwingSet2 with the OGL pipeline enabled? Thanks, Chris.
|
|
|
|
swpalmer
|
 |
«
Reply #48 - Posted
2006-01-16 14:04:58 » |
|
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.
Sorry, I think that was a false alarm.
|
|
|
|
GKW
|
 |
«
Reply #49 - Posted
2006-01-21 17:12:49 » |
|
Would it be possible to have the twinkle and jbutton programs available again? The links on the last page are not longer good.
|
|
|
|
Gfx
Junior Newbie
|
 |
«
Reply #50 - Posted
2006-01-24 23:44:15 » |
|
|
|
|
|
GKW
|
 |
«
Reply #51 - Posted
2006-01-28 20:56:20 » |
|
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.
|
|
|
|
vernier
Senior Newbie 
Java rock!
|
 |
«
Reply #52 - Posted
2006-03-18 22:20:56 » |
|
I'm experiencing a problem with the Java2D/JOGL Interoperability.
The first one is it crashes when I exit as soon as I activate the flag -Dsun.java2d.opengl=true I've read it may come from the nvidia driver and I do weird things with my nvidia driver (I've installed a GeForce forceware82.10 driver on a Quadro FXGo700 to enhance perfs) so I'll have to test on a clean computer before I can complain ;-)
The second one is an incompatibility question between the flag -Dsun.java2d.opengl=true and -Dopengl.1thread=awt when 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 get Thread.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
Fred
|
|
|
|
keith_myers
Senior Newbie 
|
 |
«
Reply #53 - Posted
2006-03-30 19:34:56 » |
|
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.
//=====( Begin constructor )=================================================
/** * Get the JFrame, rendering canvas, and rendering thread set up. */
public GL_Game_Core() { // Create GLCanvas, and do setup involving it // GLCanvas canvas = new GLCanvas(new GLCapabilities()); GLJPanel canvas = new GLJPanel(new GLCapabilities());
canvas.addGLEventListener(this); getContentPane().add(canvas); animator = new Animator(canvas);
// Make adjustments to the JFrame setUndecorated(true); setResizable(false);
// Go into fullscreen mode DisplayMode displayMode = new DisplayMode( SCREEN_WIDTH, SCREEN_HEIGHT, BITS_PER_PIXEL, REFRESH_RATE); GraphicsEnvironment environment = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice device = environment.getDefaultScreenDevice(); device.setFullScreenWindow(this); device.setDisplayMode(displayMode);
// Start the rendering thread setVisible(true); animator.start(); canvas.requestFocus(); }
//=====( End Constructor )=================================================== ///////////////////////////////////////////////////////////////////////////// //=====( Begin init() )======================================================
/** * Do all one-time-only setup operations. */
public void init(GLAutoDrawable drawable) { // Get current GL and GLU GL gl = drawable.getGL();
// Create the GLUT object glut = new GLUT(); glu = new GLU();
// Get TextureManager instance textureManager = TextureManager.getInstance(gl, glu);
// Enable basic OpenGL functions gl.glEnable(GL.GL_LIGHTING); gl.glEnable(GL.GL_DEPTH_TEST); gl.glEnable(GL.GL_CULL_FACE);
// Set state variables gl.glHint(GL.GL_PERSPECTIVE_CORRECTION_HINT, GL.GL_NICEST); gl.glClearColor(0.0f, 0.0f, 0.0f, 1.0f); gl.glClearDepth(1.0f); gl.glDepthFunc(GL.GL_LEQUAL); gl.glShadeModel(GL.GL_SMOOTH); gl.glCullFace(GL.GL_BACK);
// Create and setup camera instance camera = new Camera(baseCameraMoveRate, baseCameraRotationRate, eyeX, eyeY, eyeZ, centerX, centerY, centerZ, upX, upY, upZ);
// Create object to manage key and mouse events inputManager = new InputManager((Component)drawable); // Get rid of the cursor inputManager.setCursor(InputManager.INVISIBLE_CURSOR); // Create the LightManager lightManager = LightManager.getInstance(gl, camera);
// Wire up key and mouse commands createGameActions();
// Do initialization that is specific to the extending class initGameSpecificCode(gl, glu);
// The game is about to start, so get the start time for time-based // movement and frames per second calculations currentTime = System.nanoTime(); startTime = currentTime; }
//=====( End init() )========================================================
Thanks much,
Keith
|
|
|
|
Ken Russell
|
 |
«
Reply #54 - Posted
2006-03-30 21:26:21 » |
|
Are you specifying -Dsun.java2d.opengl=true on the command line? That enables the accelerated version of the GLJPanel.
|
|
|
|
mont
Senior Newbie 
|
 |
«
Reply #55 - Posted
2006-05-02 19:58:00 » |
|
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...  sorry for bothering.. cheers, mont[/b]
|
|
|
|
basszero
Senior Newbie 
Java games rock!
|
 |
«
Reply #56 - Posted
2006-05-02 21:19:05 » |
|
you need to download one of the jsr-beta releases or a nightly. Try the jsr-beta4 release. It's from April 20, 2006.
|
|
|
|
vernier
Senior Newbie 
Java rock!
|
 |
«
Reply #57 - Posted
2006-07-14 15:21:21 » |
|
What about the Mac Os X version of the Java2D/JOGL Interoperability. It is mentionned in the initial post but couldn't find any later reference. I have java 1.6.0-dp (universal binaries) on Mac OS X v10.4.7, the jogl version I use is 1.0.0-beta5 (universal binaries) and unfortunately get this message after turning a couple debug option on : JOGL specification version 1.0.0 JOGL implementation version 1.0.0-beta5 JOGL implementation vendor Sun Microsystems, Inc. OGLUtilities.UNDEFINED = 0 OGLUtilities.WINDOW = 1 OGLUtilities.PBUFFER = 2 OGLUtilities.TEXTURE = 3 OGLUtilities.FLIP_BACKBUFFER = 4 OGLUtilities.FBOBJECT = 5 Checking for Java2D/OpenGL support Java2D support: default GraphicsConfiguration = apple.awt.CGraphicsConfig JOGL/Java2D integration disabled
Am I doing something wrong or is the Java2D/Jogl bridge not enabled yet on Mac OS X ?
|
|
|
|
Ken Russell
|
 |
«
Reply #58 - Posted
2006-07-14 18:23:29 » |
|
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.
|
|
|
|
samkass
Junior Newbie
|
 |
«
Reply #59 - Posted
2006-07-25 01:33:30 » |
|
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.
|
|
|
|
|