Poor performances on Linux Ubuntu unless desktop effects are disabled

Hi all,

when I run my Java3D applications on Ubuntu 12.04 or Ubuntu 14.04 (64 bit) I get very poor performances: the animations are not smooth, with frequent gaps or jumps between frames and/or a strange "flickering" effect. The only workarounds I found are the following:

1) Upgrade to JogAmp Java3D 1.6.0 and disable V-Sync. With V-Sync activated the animations seem "flickering" independently from the Java3D version, even when the frame rate is good (60 fps) and no frames seem to be lost. On the other hand, it seems that disabling V-Sync increases too much the frame rate and the CPU percentage, and this leads again to gaps and jumps in the animations (and setting the minimum.frame.cycle.time property doesn't seem to be a remedy)... With older versions of Java3D the performances are always poor, even deactivating V-Sync.

2) Disable destktop effects. We can do this choosing a "Unity 2D" session or a "Gnome classic - no effects" session when I log in. In these cases the performances are quite good whatever Java3D version is used. On the other hand we have to renounce to the Ubuntu 3D desktop with all the effects that are usually very appreciated.

I experimented this behaviors with different hardware configurations and I have to notice that on Windows XP, even with very old hardware and old versions of Java3D, the animations are always perfectly smooth... On Windows 7 the performances are quite good, but not so good. I can obtain better results choosing a basic desktop theme instead of an aero theme. Even in this case it seems that the performances are related to the desktop effects. Perhaps I'm saying obvious things but I'm not an expert of 3D issues...

Finally, the question is: can you suggest me a way to have smooth animations in Ubuntu 3D keeping the V-Sync setting activated? I mean, through some driver settings or Java3D settings... And, of course, do you agree with my observations? Maybe I'm doing something wrong... But even using a demo Java 3D application with a simple rotating cube I get the same results...

Thanks very much for your attention, any help will be very appreciated.

Riccardo.

Hi

At first, we only maintain Java3D 1.6.0, we won't give you any help if you use older versions as I explained here.

Secondly, please give much more information about your hardware. Mentioning your operating system isn't enough. Some Java3D users are under Fedora, Red Hat, Debian, ... I'm under Mageia Linux 4 and Java3D works flawlessly. Your operating system is probably not the culprit. Which version of OpenJDK / Oracle Java do you use?

Thirdly, just run glxgears with Unity + 3D desktop and then with Unity 2D. You'll see that your problem has nothing to do with JOGL in particular but rather with OpenGL use with 3D desktop like in this case:
http://ubuntuforums.org/showthread.php?t=2002029
http://askubuntu.com/questions/68379/slow-and-laggy-animations

and it should have been fixed:
http://www.phoronix.com/scan.php?page=article&item=ubuntu_unity_512&num=1

GNU Linux in general isn't to blame. I use 2 very old graphics card at home, ATI Radeon 9250 Pro AGP and a crappy Intel chipset sold in 2007, it works smoothly except with WebGL that blacklists the former but not the latter and it is a lot slower than Java3D, Ardor3D and their "friends".

Please try to reproduce your problem with OpenGL applications and utilities not relying on JOGL and Java3D in order to confirm there is effectively a problem with OpenGL and 3D desktop under Ubuntu.

You remind me that I have to improve my tutorial. When you're under Windows, you should use some JVM options to disable the Direct3D pipeline.

You aren't accurate enough, there should be many possible explanations. In my humble opinion, as you have a problem even with a simple rotating cube, I think that there are a couple of things wrong on the machines you tested, maybe your drivers under Windows need an update and you have to use the manufacturer's drivers instead of the crappy OpenGL emulation through Direct3D (Microsoft GDI renderer).

Please give us this info about each machine you use for your test:
- version number of the operating system (indicate whether you use unofficial patches, use uname -a under GNU Linux)
- version number and name of the OpenGL driver
- manufacturer (ATI, Nvidia, Intel, Matrox, ...)
- information about the JVM (java -version)

Please try to run some simple JOGL applications and enable all logs:
http://jogamp.org/wiki/index.php/Jogl_FAQ#Detailed_Debug_Log

Best regards.

Edit.: You can use this simple example:
http://en.wikipedia.org/wiki/Java_OpenGL#Code_example

Hi Julien,

thank you so much for your quick and detailed reply. I was not intended to ask help for older versions of Java3D, I only referred them just to explain what has changed, and what has not, with the newer version.

The hardware I'm using now is:

- Intel Core 2 Duo E7400 2.80GHz
- GPU NVIDIA GeForce GTS 450
- Display Samsung Syncmaster 1920x1080 60Hz
- 4GB RAM
- Mother board MSI G41M-P33, same behavior with previous ASUS P5N73-CM

The software details are reported below.

$ uname -a
Linux ubuntu-1204 3.2.0-67-generic #101-Ubuntu SMP Tue Jul 15 17:46:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ glxinfo | grep "OpenGL version"
OpenGL version string: 4.2.0 NVIDIA 304.116

$ unity --version
unity 5.20.0

$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

The glxgears application seems behaving like the Java3D applications: when V-sync is ON in an Ubuntu 3D session, I can see that the borders of the wheels are not clear, but they are vibrating. It's like if a V-sync could not be realized, the frame rate is exactly 60Hz but the animation is not good. On the contrary, in Ubuntu 2D or "Gnome Classic - No effects" sessions (available through the package gnome-session-fallback) the animations are perfectly smooth with V-sync activated. When I set V-sync OFF I get quite good results both in Ubuntu 3D and Ubuntu 2D / gnome classic sessions. Without resizing the window, the frame rates of the glxgears application are summarized below:

Ubuntu 3D: 9000 FPS
Ubuntu 2D: 4500 FPS (but better animation)
Gnome Classic - No effects: 17000 FPS

Regarding the Java3D / JOGL sample application, I chose a simple rotating cube application that you can find here.

I chose this sample because it is a very regular motion and any defects can be easily detected by our eye. We can observe the borders of the color cube and it's very easy to notice the enormous differences of quality and smoothness among the different environments and settings. The results of the comparation are the following:

Ubuntu 3D, V-Sync ON: very poor.
Ubuntu 3D, V-Sync OFF: just acceptable.
Ubuntu 2D, V-Sync OFF: quite good.
Ubuntu 2D, V-Sync ON: good.
Gnome Classic - NO effects, V-Sync OFF: good.
Gnome Classic - NO effects, V-Sync ON: very good.

Unfortunately, examining the frame rates of all these cases does not tell us anything because they are good in each case: when V-Sync is ON, the frame rate is always 60Hz without gaps, and whan V-Sync is OFF it is always very high. I measured the FPS extending the RotationInterpolator class, I don't know if there is a better way to do this.

Of course, the more the application is complex and/or the window size is large, the more the defects of the animation are noticeable. Maybe these problems could be tolerated in a very simple application like glxgears or the rotating cube, but in more complex scenes the resulting smoothness and quality are not so good, or even poor, on Ubuntu 3D.

Regarding the links you posted please read the comments below.

1) http://ubuntuforums.org/showthread.php?t=2002029

This seems not related to my problem. The post speaks of a FPS of 2.5 while I have a very high frame rate on Ubuntu 3D.
Rather, my problem seems dealing with this: http://forum.jogamp.org/V-SYNC-causes-choppy-animations-td4029992.html.

2) http://askubuntu.com/questions/68379/slow-and-laggy-animations

I tried all the suggested options in the Compiz Config Settings manager, but without any improvement. On the contrary, the smoothness has worsened and I came back to the default settings.

3) http://www.phoronix.com/scan.php?page=article&item=ubuntu_unity_512&num=1

As you can see from my software details, I have Unity 5.20 and I still have problems.

Regarding the JOGL logs: I activated them in the sample application (through the settings -Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all) but I obtain a lot of information that I cannot understand. Most of the logs are identical for the different options / environments, and I don't know what to look for. If you think they could be useful I can attach them.

Regarding Windows: I use the updated manufacturer's drivers. When you speak of disabling Direct3D pipeline, what do you mean? Is it not sufficient to set the j3d.rend property to ogl or jogl?

I hope that all those details help you to better understand what could be the issue.
Thank you again and best regards,
Riccardo.

Just to say that I had mistaken the following summary. Now it is corrected also in the previous post.

Ubuntu 3D, V-Sync ON: very poor.
Ubuntu 3D, V-Sync OFF: just acceptable.
Ubuntu 2D, V-Sync OFF: quite good.
Ubuntu 2D, V-Sync ON: good.
Gnome Classic - NO effects, V-Sync OFF: good.
Gnome Classic - NO effects, V-Sync ON: very good.

Regards,
Riccardo.

A couple of years ago I ran into similar things using compiz. I don't know what caused it but if desktop effects was on it stalled _every_ other OpenGL application. Maybe the driver couldn't keep up with the amounts of draw calls or something but it was super slow. If I disabled desktop effects I could run several OpenGL applications at the same time without much penalty but there was something in the compositing window manager that killed performance.

I was talking about : -Dsun.java2d.d3d=false -Dsun.java2d.noddraw=true

Hi

I gave you an example only based on JOGL (without Java3D) in order to check whether the problem comes from Java3D:
http://en.wikipedia.org/wiki/Java_OpenGL#Code_example

Please run it and tell us what you get. Java3D still uses under-optimized canvases as they were written with other constraints, they had to support several rendering pipelines until I removed them except the one based on JOGL of course. Therefore, I removed j3d.rend. Whatever the value you set, Java3D 1.6 will use JOGL, neither native OpenGL nor Direct3D.

Concerning Ubuntu, I fear that there is a problem with some window managers and compositing window managers, especially when enabling some "fancy" effects. I don't know your application but my first person shooter sends more than 100 000 vertexes to the graphics card and as far as I know, it works under Ubuntu and LUbuntu without trouble but it uses JogAmp's Ardor3D Continuation which is the most reliable scenegraph based on JogAmp.

You can disable Aero under Windows:
http://helpx.adobe.com/x-productkb/global/disable-windows-aero-windows-7.html

Hi Julien,

I've tested the suggested JOGL example and it behaves exactly like the Java3D applications:

Ubuntu 3D session, VSYNC ON ==> BAD behavior, flickering, vibrating borders.
Ubuntu 3D session, VSYNC OFF ==> Quite good, it is not perfectly smooth probably because the frame rate is not constant while the rotation angle increments are fixed.
LXDE session, VSYNC ON ==> GOOD, very smooth!

Also my application is very smooth under LXDE sessions with VSYNC ON. I installed the LXDE package when I read that you had not problems under Lubuntu.

At the beginning I had discarded the JOGL sample because it shows only one polygon that moves in a "strange" way (it rotates around three axes) and it seems difficult to assess.

So, I decided to transform the display() function in order to show a colored cube rotating around the Y axis. This way it was very easy to recognize the complained defect.

The modified function is reported below.

        @Override
        public void display(GLAutoDrawable gLDrawable) {
                final GL2 gl = gLDrawable.getGL().getGL2();
                gl.glClear(GL.GL_COLOR_BUFFER_BIT);
                gl.glClear(GL.GL_DEPTH_BUFFER_BIT);
                gl.glLoadIdentity();
                //gl.glTranslatef(0.0f, 0.0f, -5.0f);
               
                GLU glu = GLU.createGLU(gl);
                glu.gluLookAt(0.0f, 3.0f, -5.0f, // look from camera XYZ
                          0, 0, 0, // look at
                          0, 1, 0); // direction

                // rotate about the three axes
                //gl.glRotatef(rotateT, 1.0f, 0.0f, 0.0f);
                gl.glRotatef(rotateT, 0.0f, 1.0f, 0.0f);
                //gl.glRotatef(rotateT, 0.0f, 0.0f, 1.0f);
 
                // Draw A Quad
                gl.glBegin(GL2.GL_QUADS);      
                gl.glColor3f(0.0f, 1.0f, 1.0f);   // set the color of the quad
                gl.glVertex3f(-1.0f, 1.0f, -1.0f);   // Top Left
                gl.glVertex3f( 1.0f, 1.0f, -1.0f);   // Top Right
                gl.glVertex3f( 1.0f,-1.0f, -1.0f);   // Bottom Right
                gl.glVertex3f(-1.0f,-1.0f, -1.0f);   // Bottom Left
                // Done Drawing The Quad
                gl.glEnd();  
               
                // Draw A Quad
                gl.glBegin(GL2.GL_QUADS);      
                gl.glColor3f(1.0f, 1.0f, 0.0f);  
                gl.glVertex3f(-1.0f,-1.0f, -1.0f);  
                gl.glVertex3f( 1.0f,-1.0f, -1.0f);  
                gl.glVertex3f( 1.0f,-1.0f, 1.0f);  
                gl.glVertex3f(-1.0f,-1.0f, 1.0f);  
                // Done Drawing The Quad
                gl.glEnd();
               
                // Draw A Quad
                gl.glBegin(GL2.GL_QUADS);      
                gl.glColor3f(1.0f, 0.0f, 1.0f);  
                gl.glVertex3f(-1.0f, 1.0f, 1.0f);  
                gl.glVertex3f( 1.0f, 1.0f, 1.0f);  
                gl.glVertex3f( 1.0f,-1.0f, 1.0f);  
                gl.glVertex3f(-1.0f,-1.0f, 1.0f);  
                // Done Drawing The Quad
                gl.glEnd();  

                // Draw A Quad
                gl.glBegin(GL2.GL_QUADS);      
                gl.glColor3f(1.0f, 0.0f, 0.0f);  
                gl.glVertex3f(-1.0f, 1.0f, -1.0f);  
                gl.glVertex3f( 1.0f, 1.0f, -1.0f);  
                gl.glVertex3f( 1.0f, 1.0f, 1.0f);  
                gl.glVertex3f(-1.0f, 1.0f, 1.0f);  
                // Done Drawing The Quad
                gl.glEnd();
               
                // Draw A Quad
                gl.glBegin(GL2.GL_QUADS);      
                gl.glColor3f(0.0f, 1.0f, 0.0f);  
                gl.glVertex3f(-1.0f, 1.0f, 1.0f);  
                gl.glVertex3f(-1.0f, -1.0f, 1.0f);  
                gl.glVertex3f(-1.0f, -1.0f, -1.0f);  
                gl.glVertex3f(-1.0f, 1.0f, -1.0f);  
                // Done Drawing The Quad
                gl.glEnd();

                // Draw A Quad
                gl.glBegin(GL2.GL_QUADS);      
                gl.glColor3f(0.0f, 0.0f, 1.0f);  
                gl.glVertex3f(1.0f, 1.0f, 1.0f);  
                gl.glVertex3f(1.0f, -1.0f, 1.0f);  
                gl.glVertex3f(1.0f, -1.0f, -1.0f);  
                gl.glVertex3f(1.0f, 1.0f, -1.0f);  
                // Done Drawing The Quad
                gl.glEnd();
 
                // increasing rotation for the next iteration                  
                rotateT += 1.3f; // divide by 20 when VSYNC is OFF;
        }

It would be interesting to know how many people have the same problem, or have not, with similar or different hardware.

Regards,
Riccardo.

Ok but it's not specific to JOGL, I already had similar slowdowns and buggy animations with some OpenGL applications because of some desktop effects on poor hardware like jmaasing.

On 07/28/2014 11:14 PM, riccaricca68 [via jogamp] wrote: May I add my favorite configuration ?

GNU/Linux (Debian 8.0 / Jessie)
w/ KDE and enabled or disabled GL composite WM: All Great!

As Julien mentioned, this is not a JOGL issue at all.
Bad performance here is due to poor composite WM implementation
and/or a not so fast GPU. The latter should no more be an issue today though.

~Sven

I just insist on one important aspect: it's not a general problem, it occurs with some particular combinations of GPUs, drivers, compositing window managers, desktop effect(s) and rendering pipeline (XRender or OpenGL). I mostly use very old GPUs without such problems.

Sven Gothel wrote

May I add my favorite configuration ?

GNU/Linux (Debian 8.0 / Jessie)
w/ KDE and enabled or disabled GL composite WM: All Great!

As Julien mentioned, this is not a JOGL issue at all.
Bad performance here is due to poor composite WM implementation
and/or a not so fast GPU. The latter should no more be an issue today though.

Hi Sven, what is your VSYNC setting? Is it ON (vsync enabled) or OFF (deactivated)?

I never said that it is a JOGL problem!.. If you read my long post above, I have problems also with the glxgears application, I don't know if it uses JOGL...

As Julien says, it may depend by a combination of many different things: drivers, Window managers, and so on...

On 07/29/2014 10:53 AM, riccaricca68 [via jogamp] wrote:
>
> Hi Sven, what is your VSYNC setting? Is it ON (vsync enabled) or OFF
> (deactivated)?

Like 'ON' until driver/app tells otherwise,
but not 'always ON'.

AFAIK .. Nvidia/AMD proprietary drivers has such flags.

For Mesa/Radeon .. oh well, you need to do magic things:

Put that into e.g. '/etc/X11/xorg.conf.d/20-radeon.conf':
+++
Section "Device"
    Identifier "Radeon"
    Driver "radeon"
    Option "EnablePageFlip" "on"
    Option "SwapBuffersWait" "on"
    Option "EXAVSync" "on"
    #Option "EXAPixmaps" "off"
EndSection
+++

However, your mileage may vary here.
AFAIK I turned on KDE's composition VSYNC (always)
to avoid tearing.

~Sven