next »

[horati]

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

Code:

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

Using the head (xith 1804 and xith-tk 2104), I was able to reproduce that result.  Additionally, I got the following assertion error at the end of the successful test runs

Code:

$ ./run.sh org.xith3d.benchmarks.BouncingBallsBenchmark -o LWJGL -X -V
Initializing JOODE...ok
BouncingBallsBenchmark started to last for 30 seconds. (Hit ESC to cancel.)
java.lang.AssertionError: 2.4414062E-4
        at net.java.dev.joode.stepper.lcp.BaraffLCPFixedStatic.driveInToRange(BaraffLCPFixedStatic.java:272)
        at net.java.dev.joode.stepper.lcp.BaraffLCPFixedStatic.computeForces(BaraffLCPFixedStatic.java:153)
        at net.java.dev.joode.stepper.EulerStepper.step(EulerStepper.java:400)
        at net.java.dev.joode.stepper.StepUtils.dxProcessIslands(StepUtils.java:121)
        at net.java.dev.joode.World.stepEuler(World.java:400)
        at net.java.dev.joode.World.step(World.java:366)
        at org.xith3d.physics.simulation.joode.JoodeSimulationWorld.stepImpl(JoodeSimulationWorld.java:243)
        at org.xith3d.physics.simulation.SimulationWorld.step(SimulationWorld.java:554)
        at org.xith3d.physics.simulation.SimulationEngine.step(SimulationEngine.java:184)
        at org.xith3d.physics.simulation.SimulationEngine.update(SimulationEngine.java:220)
        at org.xith3d.physics.PhysicsEngine.update(PhysicsEngine.java:146)
        at org.xith3d.base.Xith3DEnvironment.updatePhysicsEngine(Xith3DEnvironment.java:191)
        at org.xith3d.loop.RenderLoop.prepareNextFrame(RenderLoop.java:591)
        at org.xith3d.loop.RenderLoop.loopIteration(RenderLoop.java:638)
        at org.xith3d.loop.RenderLoop.update(RenderLoop.java:698)
        at org.xith3d.loop.UpdatingThread.nextIteration(UpdatingThread.java:487)
        at org.xith3d.loop.RenderLoop.nextIteration(RenderLoop.java:709)
        at org.xith3d.loop.RenderLoop.loop(RenderLoop.java:762)
        at org.xith3d.loop.UpdatingThread.run(UpdatingThread.java:540)
        at org.xith3d.loop.RenderLoop.run(RenderLoop.java:785)
        at org.xith3d.loop.RenderLoop.begin(RenderLoop.java:841)
        at org.xith3d.loop.RenderLoop.begin(RenderLoop.java:863)
        at org.xith3d.benchmarks.BenchmarkBase.startBenchmark(BenchmarkBase.java:117)
        at org.xith3d.benchmarks.BouncingBallsBenchmark.main(BouncingBallsBenchmark.java:301)
Rendered frames: 2304
Average FPS: 541.3851
Triangles in the scene: 21120

with the number in the assertion changing only when I alter the execution options.

[Marvin Fröhlich]

Code:

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

The JOGL_SWING canvas can only be used in a swing environment. It simple doesn't make sense anywere else. Hence the exception, that should tell you about this. Unfortunately the message doesn't seem to be clear enough.

Using the head (xith 1804 and xith-tk 2104), I was able to reproduce that result.  Additionally, I got the following assertion error at the end of the successful test runs

with the number in the assertion changing only when I alter the execution options.

Actually we should write an inplementation of the physics abstraction for something like JBullet to finally replace the binding to dead Joode. Who jumps in here?

Marvin

[boogie]

Hi Marvin,

just a note on the bug.

The JOGL_SWING canvas can only be used in a swing environment. It simple doesn't make sense anywere else. Hence the exception, that should tell you about this. Unfortunately the message doesn't seem to be clear enough.

As I originally reported the bug elsewhere, this is exactly how I interpreted the message.

Unfortunately, and this seems the real bug (application design), the problem arised with the Xith3D demos itself, which don't seem to use Swing components and therefore prevent from using them as performance indicator with option "JOGL_SWING".

However, I, as the user, really expect to be able to test "JOGL_SWING". Therefore, I wouldn't expect to drop the option "JOGL_SWING" from the option menu, instead fix the problem to provide a test case for performance tests "Swing vs. AWT performance" in the special case.

[Marvin Fröhlich]

Well, this really isn't a bug. The exception just tells you, what's going on and what you have to change. JOGL_SWING is not meant to be used for performance tests. It is more a fallback, if you really cannot use anything else. In 99% of all cases you can use something better.

On the other hand it won't hurt to add this feature to the testcases which I have done now. I am not particularly happy with the solution, because I don't want people to use JOGL_SWING this way. But here you have your solution.

Marvin

[horati]

If we are going to support Swing as a platform, then it needs to be fully supported.  All tests need to run using it.  If we do not want to support it, we need to change the list of supported platforms to exclude Swing.  For any platform that we do not test regularly, we need to list it as "unsupported but usually works".

People who evaluate which project to use rely on our self-reported list of supported platforms.  Prior to selecting Xith, they do not know what they do not know so we need to warn them if a platform is not really supported.

[Marvin Fröhlich]

Swing IS supported using JOGL_AWT or LWJGL_AWT. JOGL_SWING is not the layer for swing support. It is more of a fallback to be used in certain swing circumstances where performance doesn't matter at all and you really need it. The Q3FlightDemo runs at ~800 FPS using LWJGL and at 125 using JOGL_SWING on my system. This emphesizes, that this layer is not the one to be used in any Swing environment. Maybe the name JOGL_SWING was a bad idea.

Well, all tests do work using any layer from the list now. Though JOGL_SWT is excluded from the list, since it really doesn't make sense without an SWT environment (just like JOGL_SWING).

Marvin

[boogie]

Hi Marvin,

Swing IS supported using JOGL_AWT or LWJGL_AWT...

Using JOGL_AWT, Swing painting is not supported. There are big differences between the rendering of AWT (heavyweight) and Swing (leightweight) components.

First of, all mixing AWT and Swing components is a "no go", as this is officially stated by the Java community. As JOGL_AWT does not seem to be lightweight, it is not Swing and will not support Swing. This is one major issue found with the way JOGL_AWT will draw the 3D canvas. If there are overlapping components or components in layers above the canvas - the glass pane of the underlying JFrame might be an example -, they don't draw correctly. Even if you don't use transparent colors at least drawing the background of any Swing component, which is not opaque, will not yield expected results. As an example: an empty JPanel in the glass pane would make the canvas invisible, instead some default background color will be painted instead.

Therefore, JOGL_AWT will neither behave like, nor support expected Swing behavior.

Although Swing classes are subclasses of AWT Component or Container, they aren't AWT components.

My latest experiments with Java3D Swing canvas yielded much better performance compared to the latest Xith3D releases even with AWT rendering chosen. My conclusion: Swing rendering must not necessarily be slow. It is slow, if it is implemented the way to be slow.

[Marvin Fröhlich]

Did you have a look at the SwingIntegrationTest or SwingOverlayTest in xith-tk? Maybe they are not what you need, since the Swing components have to be fully over the canvas (not partially overlapping). But possibly you didn't notice.

Marvin

[boogie]

Hi Marvin,

yes, I checked the samples mentioned. They won't work for me. This is not related on partial or complete overlapping. The issue is lack of transparency.

Although it is not very obvious from the samples (because the 3D scene is small compared to the background region and placement of the swing components), you might have noticed, even a simple JPanel, which is not opaque, fully transparent and therefore invisible by default, will fill its complete clipping rectangle with certain color over the AWT canvas. Not to mention transparent colors.