next »

[boogie]

Hi all!

I'm currently testing a Java app created with Xith3D/JOGL on certain hardware using a GMA500 Intel chip set and running on Ubuntu Linux. On the developer machines (NVIDIA graphics) the app created up to 90 fps. However, after deployment on the PC with Intel graphics on board fps dropped to only 7 fps.

glxgears is running fast with the machine and providing up to 90 fps OpenGL rendering at full screen, but Xith3d will not provide any reasonable frame rate, above 5-7 frames. Vsync is disabled, JOGL_SWING rendering. JOGL_AWT yields an exception on this machine. However, this is not critical, as swing rendering is required.

We double checked everything: packages installed, shared lib dependencies, ... but did not find any discrepancy between glxgears and JOGL library dependencies. Therefore we found no hint, why hardware acceleration don't seem to work with Java/Xith3D on the machine.

Any ideas where to look, how to convince that machine to use hardware OGL acceleration?

Thank you in advance.

Have a nice day!

[horati]

Why are you using Swing rendering?  There's a lot of slowness in that area in general.  Depending on what you need to do, we might be able to suggest a faster UI design.

Having said that, I'm not sure why the difference is so extreme compared to your development machines.  Could you run several of the xith-tk benchmark applications on both machines and report the results?

[boogie]

Horati,

I welcome your fast response. Not to say, I appreciate Xith3d, which seems a bit overkill compared to the current state of Java3D, but running smoother - if it is running.

Why are you using Swing rendering? 

Because of UI design decisions. Not to say, we currently are experimenting with both Xith3D and Java3D, as both technologies have their advantages, drawbacks and issues with certain device hardware. Just to get more flexibility and certainty to get one technology running with a certain device. Unfortunately Java3D is not running on certain machines, so Xith is an option in such cases.

There is an interface between these and the application layer. UI design layers of both technologies are too special and proprietary to derive any universal solution from both. Therefore, Swing layer over any Swing 3D canvas is the best choice for any general architecture. Anyway, the reason why shall not  be topic of my question.

There's a lot of slowness in that area in general.  Depending on what you need to do, we might be able to suggest a faster UI design.

Here I have to correct myself: The Xith3D AWT canvas is crashing on that machine however, therefore any different approach would not work. Anyway, it would not be useful for us. For example, AWT does not provide easy transparancies for overlay controls, Drwaing them pixel by pixel by the application is not a choice in this case. Therefore I can ignore this fact.

Anyway, 25 fps would be great for our purpose. 90 fps is more than expected, but 7 fps with Xith is horrible. Indeed. I cannot explain this simply by using offscreen drawing or using Swing components in general. Even a native bitmap conversion by using the main processor would be a lot faster than the handbrake seen here. Also we tested with no Swing overlay components (thus not any transparency) and got the same result from the simple Swing Canvas drawing context. Frame rate will not extend to more than 7 fps.

I have absolutely no idea, why any OpenGL benchmark is running much faster than the combination of Xith3D/JOGL. Is seems, as if Xith3D would not use hardware acceleration on that machine.

Having said that, I'm not sure why the difference is so extreme compared to your development machines.  Could you run several of the xith-tk benchmark applications on both machines and report the results?

I would give it a try, if this would be the last option. We currently are evaluating a general software architecture and a lot of issues with all those 3D frameworks in general. Thus, evaluating Xith3D features, which we don't need, is not in my focus.

[boogie]

Finally, I decided to try the Xith3D examples: Tested the Xith3d Demos with the libs and jars taken from a freshly downloaded version 0.9.7 with the machine choosing JOGL_AWT, no V_SYNC. Java version installed is "1.6.0_15".

Bouncing Balls resulted in very poor performance of 18.17 fps compared to our developer machines (214 fps). This confirms Swing will not be responsible for such a poor performance, while native Open GL apps are running much faster on the same machine. "glxgears" again resulted in 93 fps on the same machine (reproducible).

Unfortunately choosing "JOGL_SWING" from the options will cause an exception with every demo of the testlauncher. Any suggestions, what the xith demo is missing here?
(Think this might be a bug in the examples, not keeping the canvas within a container.)

---------------------------------
java.lang.Error: The CanvasPeerImplSwing must be used with an owner (integrated into an AWT/Swing environment).
   at org.xith3d.render.jsr231.CanvasPeerImplSwing.<init>(CanvasPeerImplSwing.java:161)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
...

[boogie]

Update:

Looking into sources of JOGL I found options to be set via command line. So the result for the machine mentioned above is, it uses software rendering with both AWT and Swing components of Xith, although hardware rendering is supported. There seems no workaround, as JOGL will provide poor performance with both cases AWT and Swing - even with the Xith examples.

A different machine supports hardware rendering only with Xith JOGL_AWT. It will not work with JOGL_SWING due to an exception thrown within JOGL's GLJPanel (Exception message sounds like: "javax.media.opengl.GLException: Unable to create OpenGLContext..."). This happens with an Ubuntu Intel 965 graphics driver.

Is there any workaround for the 2. case?

Would it be possible with Xith3d to render offscreen and access any bitmap/image content of a (invisible) AWT canvas to transfer its contents manually into a JComponent? I did not found a quick solution from having looked into the Xith sources.

[Marvin Fröhlich]

Would it be possible with Xith3d to render offscreen and access any bitmap/image content of a (invisible) AWT canvas to transfer its contents manually into a JComponent? I did not found a quick solution from having looked into the Xith sources.

Even if this would be possible, I really wouldn't advice you to do so. I would expect even worse performance than with the JOGL_SWING layer.

JOGL_SWING copies the back buffer to the Swing context after every rendered frame. This is slow!

It should be perfactly possible to use a JOGL_AWT canvas in a Swing environment. If you want to use Swing overlay components on top of the canvas, you should consider using the Xith HUD, which is pretty powerful and very fast.

I don't remember the last state of the LWJGL_AWT layer. But it might be an option for you.

Please don't use the binary release. You might have noticed, that if is fairly outdated. Just checkout the sources from SVN and create jars. There are a lot of bugs fixed compared to the last binary release and some new features.

Marvin

[rwb1977]

What is your -Xmx memory setting set to?  I have found that integrated intel graphics chipset graphics drivers have problems being loaded at all by the jvm if the heap memory setting is too high.

[Marvin Fröhlich]

What is your -Xmx memory setting set to?

I use the default.

[horati]

Thanks for trying out the demos on your hardware for us.

Bouncing Balls resulted in very poor performance of 18.17 fps compared to our developer machines (214 fps). This confirms Swing will not be responsible for such a poor performance, while native Open GL apps are running much faster on the same machine. "glxgears" again resulted in 93 fps on the same machine (reproducible).

Moving from the NVIDIA developer machine to an onboard graphics machine, the CPU speed is very important.  What is your deployment CPU?  If it's extremely slow (i.e., several generations old) then that could be the entire problem.
 
Marvin, do you have any ideas about why this might be happening?  Clearly, the bouncing balls demo should normally run faster than this even with onboard graphics.  On my test laptop (Intel Core Duo with ATI Mobility Radeon X1600) which is several CPU and graphics generations behind, I get the following running the bouncing balls demo

• 489 FPS (JOGL_AWT Fullscreen)
• 474 FPS (JOGL_AWT Windowed)
• 562 FPS (LWJGL Fullscreen)
• 581 FPS (LWJGL Windowed)
• CRASH (JOGL_SWING Fullscreen)
• CRASH (JOGL_SWING Windowed)

using a quick script (run.sh) to construct the classpath and the following command line

Code:

./run.sh org.xith3d.benchmarks.BouncingBallsBenchmark -o JOGL_AWT -X -V [-f 1680 1050]

Unfortunately choosing "JOGL_SWING" from the options will cause an exception with every demo of the testlauncher. Any suggestions, what the xith demo is missing here?
(Think this might be a bug in the examples, not keeping the canvas within a container.)

---------------------------------
java.lang.Error: The CanvasPeerImplSwing must be used with an owner (integrated into an AWT/Swing environment).
   at org.xith3d.render.jsr231.CanvasPeerImplSwing.<init>(CanvasPeerImplSwing.java:161)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
...

I'll copy this to a bug thread along with a bug that I discovered as well.

Please don't use the binary release. You might have noticed, that if is fairly outdated. Just checkout the sources from SVN and create jars. There are a lot of bugs fixed compared to the last binary release and some new features.

Is it time to delete/deprecate the "release" since it is essentially useless and people should always use the trunk?

[Marvin Fröhlich]

Marvin, do you have any ideas about why this might be happening?

No, sorry. Not without testing, which I don't have time nor hardware for.

Is it time to delete/deprecate the "release" since it is essentially useless and people should always use the trunk?

Yes, definitely. Maybe we should also create a new cooker release, so that people, who don't want to checkout the source, have something to play around with.

Marvin

[boogie]

Hi Marvin,

Thank you for support.

Even if this would be possible, I really wouldn't advice you to do so. I would expect even worse performance than with the JOGL_SWING layer.
JOGL_SWING copies the back buffer to the Swing context after every rendered frame. This is slow!

I dont' care about the 20 percent loss of FPS using Swing or any further native bitmap conversion. My problem is a loss of 80-95% of the frame rate and/or environments not working anyway.

It should be perfactly possible to use a JOGL_AWT canvas in a Swing environment. If you want to use Swing overlay components on top of the canvas, you should consider using the Xith HUD, which is pretty powerful and very fast.

As I said, this is not an option for us, as we don't rely on Xith only.

I don't remember the last state of the LWJGL_AWT layer. But it might be an option for you.

I even will check this option for us.

BTW: I recently checked out the binaries via SVN and remembered to haven't found any source file beeing younger than of year 2008. So what really is outdated between the latest binary and the source? I'm asking because since months I'm wondering what you are talking about last minute changes, fixes, and so on. On the other hand, if you will not provide a binary release the current source release would also be UNTESTED. Thus, I don't see a big difference difference in the sense of having a more stable version from the source. ;-)

The different JOGL versions 1.1.x also seem to cause some conflicts with different machines. Yesterday I noticed JOGL 2 seemed to be moved again to some privately hosted site and many of the GLXxxx classes refactored and moved to a subpackage not beeing compatible with Xith in any way.

Thank you in advance!

[boogie]

What is your -Xmx memory setting set to?

As this could be a helpful hint, I checked this option. The devices have 2GB of memory. I tried a few settings between 32M and 1000M for the min/max heap size. This did not change anything. The intel 965 still not working anyway, the other device slow as ever.

Do you have any more advice for the correct settings?

---

BTW: The intel 965 machine crashes within GLJPanel due to an InvocationTargetException in method display(). However when looking into JOGL sources, I get no idea what is happening. A simple runnable tried to call the method paintImmediately() on the Swing component. Maybe some driver OGL functions are not implemented here??? I currently use Xith 0.9.7 with JOGL 1.1.1 rc7, which seems one of the latest source distributions. I think JOGL gets confused about the drivers...

[horati]

BTW: I recently checked out the binaries via SVN and remembered to haven't found any source file beeing younger than of year 2008. So what really is outdated between the latest binary and the source? I'm asking because since months I'm wondering what you are talking about last minute changes, fixes, and so on. On the other hand, if you will not provide a binary release the current source release would also be UNTESTED. Thus, I don't see a big difference difference in the sense of having a more stable version from the source. ;-)

I don't understand how the latest file you have is from 2008.  I did a quick (incomplete) check and found files from 22 May 2010.

[boogie]

I don't understand how the latest file you have is from 2008.  I did a quick (incomplete) check and found files from 22 May 2010.

In fact, I checked sources out on 03 Mai 2010, so all local files have this timestamp. But, I remembered to have browsed the SVN repository via web with a colleague a few weeks ago to check the file dates. Beginning of this week, I tried to sync with the repository and did not receive any change. Your post tells me, I should have seen your changes of 22 Mai 2010. Will the SVN documentation on your main webpage tell me the correct access paths to the SVN repository, or did I miss something?

[horati]

Actually, they were Marvin's changes; he's the primary developer.

Yes, the instructions should be correct.  Personally, I use Subclipse (an Eclipse plug-in).

• You want to use these repositories:
  
  • https://xith3d.svn.sourceforge.net/svnroot/xith3d
  • https://xith-tk.svn.sourceforge.net/svnroot/xith-tk
• navigate to the /trunk directory in each
• Choose "Checkout..."
• Choose "Check out as a project in the workspace"
  

If you run on Linux, then you're already setup.  If you run on another platform, you'll have to set your native code libraries appropriately.

The standard svn way documented on the home page should be correct:

Code:

svn co https://xith3d.svn.sourceforge.net/svnroot/xith3d/trunk xith3d
svn co https://xith-tk.svn.sourceforge.net/svnroot/xith-tk/trunk xith-tk