next »

[boogie]

Hi horati,

Thank you.

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

Checked this yesterday. My SVN settings were set correctly, finally SVN reported class changes on monday.

[boogie]

Hi all,

I am unable to check the latest source distribution, instead I got this exception:

As asked before, it is not quite clear which version of which jar (Jagatoo, JOGL, ...) to use with the current distribution.

Any more advice than simply check out the latest source trunk?



Exception in thread "main" java.lang.NoClassDefFoundError: org/jagatoo/geometry/GeomNioData
        at org.xith3d.render.jsr231.StateUnitPeerRegistryImpl.<init>(StateUnitPeerRegistryImpl.java:69)
        at org.xith3d.render.jsr231.CanvasPeerImplBase.createRenderPeer(CanvasPeerImplBase.java:84)
        at org.xith3d.render.jsr231.CanvasPeerImplBase.createRenderPeer(CanvasPeerImplBase.java:63)
        at org.xith3d.render.CanvasPeer.<init>(CanvasPeer.java:110)
        at org.xith3d.render.jsr231.CanvasPeerImplBase.<init>(CanvasPeerImplBase.java:89)
        at org.xith3d.render.jsr231.CanvasPeerImplSwing.<init>(CanvasPeerImplSwing.java:155)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at org.xith3d.render.Canvas3DFactory.create(Canvas3DFactory.java:132)
        at org.xith3d.render.Canvas3DFactory.create(Canvas3DFactory.java:166)
        at org.xith3d.render.Canvas3DFactory.create(Canvas3DFactory.java:338)
        at org.xith3d.render.Canvas3DJPanel.<init>(Canvas3DJPanel.java:280)
        at org.xith3d.render.Canvas3DJPanel.<init>(Canvas3DJPanel.java:296)
        at org.xith3d.render.Canvas3DJPanel.<init>(Canvas3DJPanel.java:366)
        [...]
Caused by: java.lang.ClassNotFoundException: org.jagatoo.geometry.GeomNioData
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        ... 21 more

[Marvin Fröhlich]

You just have to checkout the complete trunk. There is a ready-to-use-eclipse project in it. Use it. Don't create a new eclipse project based in the trunk. You would have to include all the jars, which is already configured.

Marvin

[boogie]

Hi Marvin,

Thank you, again.

I already checked out the whole trunk.

Just tried to switch to the source release, picked up all necessary libs and jars given with the source distribution. Now the application will hang as soon as it enters InputAdapterRenderLoop.begin(). No exception, no crash, no exit, just hanging forever with 100% CPU usage. Due to any strange reason it is not possible to enter the method with debugger to see what is happening inside.

However the method is documented to use Milliseconds, but coded to use microseconds. Therefore I also tried begin(RunMode.RUN_IN_SAME_THREAD, TimingMode.MILLISECONDS); without any success.

Switching back to the latest binary release, the app will work again.

begin(RunMode.RUN_IN_SEPARATE_THREAD, TimingMode.MILLISECONDS); finally worked.

However, comparing both, the latest binary release and the current source distribution, again a drop of performance is found in the latest source distribution.

(BTW: I'm working on netbeans, however this is not a real problem to build the jar.)

[Marvin Fröhlich]

However, comparing both, the latest binary release and the current source distribution, again a drop of performance is found in the latest binary.

The source is newer. It is one of the reasons, why I advice do use the source instead of the binary release: The SVN version is much better.

(BTW: I'm working on netbeans, however this is not a real problem to build the jar.)

The SVN trunk also keeps a ready-to-use netbeans project with all libs correctly configured.

Marvin

[boogie]

Hi marvin,

I should be more precise (and corrected my post above). I wrote "latest binary", where "latest binary" meant the correct history and thus the binary compiled from the sources checked out via SVN with the latest jars found with the source distribution (jagatoo, jogl, et.).

Therefore loss of performance is related to the source from SVN. Drop of performance is found with three different machines. So the latest source finally was not found closer to solve my problem and I cannot confirm "much better".

... The SVN version is much better.

Maybe you should have a look at the RenderLoop, as the problem and bug reported is related to the source distribution from SVN. The RenderLoop obviously will cause a dead lock, when started as RUN_IN_SAME_THREAD, which is the case, if I simply called begin() without arguments in my application. Documentation tags and implementation of begin() also differ a little bit and the documentation tag argues the converse of what is really executed in the code. ;-)

   
    /**
     * Starts this rendering-loop in a separate Thread and with TimingMode.MILLISECONDS.
     *
     * @param timingMode the TimingMode to use
     */
    public final void begin( TimingMode timingMode )
    {
        begin( RunMode.RUN_IN_SAME_THREAD, timingMode );
    }
   
    /**
     * Starts this rendering-loop in a separate Thread and with TimingMode.MILLISECONDS.
     */
    public final void begin()
    {
        begin( RunMode.RUN_IN_SAME_THREAD, TimingMode.MICROSECONDS );
    }


PS: unfortunately unable to post the bug in the correct forum. However, it seems a general code review of the class RenderLoop and others is advisable, as there are many obvious bugs seen from the source (as there are some others bugs found within different class sources, which I don't remember all in detail. Anyway, I wouldn't use the current source distribution in a production environment)

[boogie]

Maybe someone can interpret the JOGL debug messages (1) and (2) for me, which are separated below for better reading, but came consecutively without a gap during debugging of JOGL.

As far as I understood, JOGL is initialized with 16 bits depth trying to fetch a pbuffer in a first step (1). After JOGL failed with that, and because the driver for the intel chipset doesn't seem to support it, it switches to software rendering.

This is a very bad idea and explains a lot of my poor performance with the intel 965 using Swing. Why? The application initializes a CanvasConstructionInfo with bit depth 24. After it fails with the wrong depth, it again tries with the correct bit depth of 24 (2) in a second step and then gets a pbuffer with correct depth and possible support of hardware rendering.

Maybe, Marvin, you can lead me to the point where this might happen.

I tried xith3d-0.9.7-dev-B1618 with JOGL 1.1.1 rc7 and rc8 - also the latest source distribution with the corresponding jars - with no success.

As it comes out, JOGL_AWT renders with 90 fps, while JOGL_SWING renders with 18 fps with the intel GPU. Thus, hardware rendering is supported, while Swing rendering seems to suffer from an incorrect JOGL init while trying to get a pbuffer for offscreen rendering.

Do you agree, that this might be the reason for the bad performance?



This is what I call a "wrong mistake".

(1)

Code:

Pbuffer caps on init: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, [b]DepthBits: 16[/b], StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
javax.media.opengl.GLException: pbuffer creation error: glXChooseFBConfig() failed
at com.sun.opengl.impl.x11.X11PbufferGLDrawable.createPbuffer(X11PbufferGLDrawable.java:126)
at com.sun.opengl.impl.x11.X11PbufferGLDrawable.<init>(X11PbufferGLDrawable.java:73)
at com.sun.opengl.impl.x11.X11GLDrawableFactory$2.run(X11GLDrawableFactory.java:311)
at com.sun.opengl.impl.x11.X11GLDrawableFactory.maybeDoSingleThreadedWorkaround(X11GLDrawableFactory.java:671)
at com.sun.opengl.impl.x11.X11GLDrawableFactory.createGLPbuffer(X11GLDrawableFactory.java:318)
at javax.media.opengl.GLJPanel.initialize(GLJPanel.java:905)
at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:488)
at javax.swing.JComponent.paint(JComponent.java:1029)
at javax.swing.JComponent.paintChildren(JComponent.java:862)
at javax.swing.JComponent.paint(JComponent.java:1038)
at javax.swing.JComponent.paintChildren(JComponent.java:862)
at javax.swing.JComponent.paint(JComponent.java:1038)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5124)
at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:278)
at javax.swing.RepaintManager.paint(RepaintManager.java:1224)
at javax.swing.JComponent._paintImmediately(JComponent.java:5072)
at javax.swing.JComponent.paintImmediately(JComponent.java:4882)
at javax.media.opengl.GLJPanel$PaintImmediatelyAction.run(GLJPanel.java:1239)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
GLJPanel: Falling back on software rendering because of problems creating pbuffer
Chosen visual (14):

(2)

Code:

GLCapabilities [DoubleBuffered: false, Stereo: false, [b]HardwareAccelerated: true[/b], [b]DepthBits: 24,[/b] StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
Created pixmap 0x600001, GLXPixmap 0x600002, display 0xffffffff8cde6138

[Marvin Fröhlich]

Please have a look at org.xith3d.render.jsr231.CanvasPeerImplSwing (constructor).

Marvin

Edit: I cannot reproduce the RenderLoop thing above. Most of the testcases in xith-tk are run in the same thread. And they all work perfectly concerning this.

[horati]

In this post, I'm only going to address the features.  I'll address the bugs in another one.

This is what I call a "wrong mistake".

So, the correct choice for your application is to change the bit depth to something supported by hardware rendering.  If I understood your post correctly as far as what you need versus what Xith chooses to do, the library chose the correct option for the general case.  There need to be some additional methods so you can query if it resulted in software rendering and allow you to choose to lower graphics quality to retain hardware rendering.  Would that be enough for your application?

Marvin, what would it take for us to do this?  Would it be possible to switch modes after determining a software rendering result?  How about providing the necessary queries prior to initializing the graphics system?

[Marvin Fröhlich]

Marvin, what would it take for us to do this?  Would it be possible to switch modes after determining a software rendering result?  How about providing the necessary queries prior to initializing the graphics system?

I am not sure, if it is even possible to detect software mode. Is there any getter to know this?

The best place for query methods like this would be abstract methods in OpenGLLayer like
supportsHardwareAcceleration()
or
getBestModeForHardwareAcceleration()
or something like that.

Marvin

[boogie]

Hi horati, hi Marvin,

So, the correct choice for your application is to change the bit depth to something supported by hardware rendering...

I'm not quite sure you understood my last post.

The strange thing here is, there is no problem to render within AWT canvas. The problem occurs when switching to JOGL_SWING. The bit depth (16) choosen within the call javax.media.opengl.GLJPanel.initialize() obviously differs from what has been set by the application (24). I found 16 the default value of the buffer bit depth within Xith3D class CanvasConstructionInfo. However, this is executed by the application:

Code:

    CanvasConstructionInfo canvasInfo = new CanvasConstructionInfo(
            OpenGLLayer.JOGL_SWING
            , width
            , height
            , 24
            , DisplayMode.WINDOWED
            , true
            , antialiasing
            , "Virtual Theater"
            );
    canvasPanel = new Canvas3DJPanel(canvasInfo);
    canvasPanel.enableLighting();
    canvasPanel.setOpaque(false);
    canvasPanel.getCanvas().setBackgroundColor(Colorf.BLACK);
    env.addCanvas(canvasPanel);

Next thing, found very strange is what happens within the Xith3D class DisplayModeSelector when setting "debug" to true. It seems, there is no display mode tried with the correct bit depth. The app sets screen to 1024x768 with bit depth 24. However, the Xith3D framework choses 800x600  with bit depth (-1) after three rounds of trying display modes with bbp=-1.

I really don't find the reason for the strange behaviour. Where will Xith3d obtain and try a bit depth of -1?

Code:

Trying to find best mode matching (Width = 1024, Height = 768 , BPP = 24)
  Found Mode 0... Width = 320, Height = 240, BPP = -1, frequency = 0
  Found Mode 1... Width = 640, Height = 480, BPP = -1, frequency = 0
  Found Mode 2... Width = 800, Height = 600, BPP = -1, frequency = 0
  Found Mode 3... Width = 1024, Height = 768, BPP = -1, frequency = 0
  Found Mode 4... Width = 1152, Height = 864, BPP = -1, frequency = 0
  Found Mode 5... Width = 1280, Height = 960, BPP = -1, frequency = 0
  Found Mode 6... Width = 1280, Height = 1024, BPP = -1, frequency = 0
  Found Mode 7... Width = 1480, Height = 925, BPP = -1, frequency = 0
  Found Mode 8... Width = 1600, Height = 1200, BPP = -1, frequency = 0
  Found Mode 9... Width = 1680, Height = 1050, BPP = -1, frequency = 0
  Found Mode 10... Width = 1920, Height = 1200, BPP = -1, frequency = 0
Using mode: Width = 1024, Height = 768, BPP = -1, frequency = 0
Trying to find best mode matching (Width = 800, Height = 600 , BPP = -1)
  Found Mode 0... Width = 320, Height = 240, BPP = -1, frequency = 0
  Found Mode 1... Width = 640, Height = 480, BPP = -1, frequency = 0
  Found Mode 2... Width = 800, Height = 600, BPP = -1, frequency = 0
  Found Mode 3... Width = 1024, Height = 768, BPP = -1, frequency = 0
  Found Mode 4... Width = 1152, Height = 864, BPP = -1, frequency = 0
  Found Mode 5... Width = 1280, Height = 960, BPP = -1, frequency = 0
  Found Mode 6... Width = 1280, Height = 1024, BPP = -1, frequency = 0
  Found Mode 7... Width = 1480, Height = 925, BPP = -1, frequency = 0
  Found Mode 8... Width = 1600, Height = 1200, BPP = -1, frequency = 0
  Found Mode 9... Width = 1680, Height = 1050, BPP = -1, frequency = 0
  Found Mode 10... Width = 1920, Height = 1200, BPP = -1, frequency = 0
Using mode: Width = 800, Height = 600, BPP = -1, frequency = 0
Trying to find best mode matching (Width = 800, Height = 600 , BPP = -1)
  Found Mode 0... Width = 320, Height = 240, BPP = -1, frequency = 0
  Found Mode 1... Width = 640, Height = 480, BPP = -1, frequency = 0
  Found Mode 2... Width = 800, Height = 600, BPP = -1, frequency = 0
  Found Mode 3... Width = 1024, Height = 768, BPP = -1, frequency = 0
  Found Mode 4... Width = 1152, Height = 864, BPP = -1, frequency = 0
  Found Mode 5... Width = 1280, Height = 960, BPP = -1, frequency = 0
  Found Mode 6... Width = 1280, Height = 1024, BPP = -1, frequency = 0
  Found Mode 7... Width = 1480, Height = 925, BPP = -1, frequency = 0
  Found Mode 8... Width = 1600, Height = 1200, BPP = -1, frequency = 0
  Found Mode 9... Width = 1680, Height = 1050, BPP = -1, frequency = 0
  Found Mode 10... Width = 1920, Height = 1200, BPP = -1, frequency = 0
Using mode: Width = 800, Height = 600, BPP = -1, frequency = 0

[Marvin Fröhlich]

The -1 for BPP is what the AWT reports for the available display modes on Linux, which is a pity.

Please add this line to CanvasPeerImplSwing line 148.
Thread.dumpStack();

This will help you finding what is executed where.

The canvas' size is defined by the containing LayoutManager. So it is simply initialized with a default size.

Hope, this helps.

Marvin

[boogie]

Hi Marvin,

The -1 for BPP is what the AWT reports for the available display modes on Linux, which is a pity.

now I understand where you got the bits per pixel. Instead using a call to the display mode (or similar)

Code:

int bpp =
        GraphicsEnvironment
            .getLocalGraphicsEnvironment()
            .getDefaultScreenDevice()
            .getDisplayMode()
            .getBitDepth();

you should prefer to call

Code:

int bpp =
    GraphicsEnvironment.getLocalGraphicsEnvironment()
        .getDefaultScreenDevice()
        .getDefaultConfiguration()
        .getColorModel().getPixelSize();

to retrieve the correct bits per pixel. This will work with the current Linux I'm working on. In case of doubt you may compare both results to avoid using (-1).

Hope this helps.