Could you explain what you mean by slowness? In the version of the demo with the Java2D/JOGL integration enabled, transparency in the GLJPanel is basically free – no performance impact at all.
[quote]Regarding full-screen, has the displayChanged() started trial implemenation? What is the current status or progress on the NURBS in jsr231? - AK77
[/quote]
We haven’t looked at displayChanged. At this point it isn’t clear to me that it is actually necessary and we may consider removing it from the API. At the current time the plan is to not have NURBS support in the initial JSR-231 API, unless we can teach GlueGen to autogenerate JNI code to interface to it.
I don’t think there are any tunable parameters in the Java2D implementation to scale back its VRAM usage. In Mustang I believe the default will be one back buffer per window having RGBA + a depth buffer. As of a recent Java2D putback it no longer uses the stencil buffer to implement some of its clipping operations, saving VRAM. You may get more information about this on the Java2D forums.
What is Motion? Is this an application you are developing or one you use?
[quote]So are you guys working towards something that’s
as fast as the heavyweight or staying with H/W
pixel copying whenever Java2D and JOGL is used
together? This will affect how I design the GUI and
workflow for my app.
[/quote]
You are using HW pixel copying whenever Java2D is in use in the context of Swing, regardless of whether JOGL is being used at the same time. I would personally like to see a solution which is based more on buffer flipping (i.e., removing the Swing assumption of a persistent back buffer), but I haven’t discussed this with anyone yet and don’t know whether it’s feasible.
I added a screenshot of the demo running on Solaris/x86 with the new NVidia drivers; hopefully this will pique everyone’s interest enough to try the web start demos.
Hi, I’m very excited about the prospects. I tried the demo but get the following error when I select any of the applications other than the default “Hello World” one that launched at startup. Is there something that I’m not doing.
My machine is Fedora Core 4, 2.6.12-1.1398_FC4 kernel, Nvidia 7676 drivers,.
Java Web Start 1.6.0-ea
Using JRE version 1.6.0-ea Java HotSpot™ Client VM
User home directory = /home/grass
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
m: print memory usage
o: trigger logging
p: reload proxy configuration
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
0-5: set trace level to
Exception in thread “AWT-EventQueue-0” javax.media.opengl.GLException: glXQueryVersion failed
at com.sun.opengl.impl.x11.X11GLDrawableFactory$2.run(X11GLDrawableFactory.java:179)
at com.sun.opengl.impl.x11.X11GLDrawableFactory.maybeDoSingleThreadedWorkaround(X11GLDrawableFactory.java:427)
at com.sun.opengl.impl.x11.X11GLDrawableFactory.canCreateGLPbuffer(X11GLDrawableFactory.java:205)
at javax.media.opengl.GLJPanel.initialize(GLJPanel.java:519)
at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:239)
at demos.jgears.JGears.paintComponent(JGears.java:56)
at javax.swing.JComponent.paint(JComponent.java:975)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:559)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:559)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:559)
at javax.swing.JComponent.paintChildren(JComponent.java:811)
at javax.swing.JComponent.paint(JComponent.java:984)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5077)
at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:279)
at javax.swing.RepaintManager.paint(RepaintManager.java:1055)
at javax.swing.JComponent._paintImmediately(JComponent.java:5025)
at javax.swing.JComponent.paintImmediately(JComponent.java:4843)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:682)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:638)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:618)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:992)
at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1320)
at com.sun.opengl.utils.Animator.display(Animator.java:158)
at com.sun.opengl.utils.FPSAnimator$1.run(FPSAnimator.java:76)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
…
I’ve run the demo on a similar driver configuration to yours with no problems. It looks like you’re using the “non-accelerated” link in your stack trace below. Does the JRefract demo on the JOGL web page (which also doesn’t use the new interoperability mechanism) work? Does the Gears demo from within it launch correctly? Does the accelerated version of the demo work?
Something like that. The Gears demo is throttled to 60 FPS max. You should see significant differences in frame rate if the Gears window is made bigger in both cases.
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
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.
[quote] 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.
[/quote]
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.
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 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.
. 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.