Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: 1. Set up environment for SWT, JOGL, LWJGL. 2. Run the attached 2 programs (Snippet195.java(for JOGL) and Snippet209.java(for LWJGL) on Windows and Linux. Their performance(frames per second) will be displayed as output, and you will find it's very slow on Windows platform. More information: At my site, both programs show approximately 60 FPS on Windows, 2,400 FPS on Linux. I used a dual-boot PC, that means the same hardware (NVIDIA Quadro FX 3450) is used for Windows and Linux. Graphic Driver is enabled for both. I tried SWT 3.2.2 and 3.3M5.
Created attachment 60136 [details] test program by LWJGL
Created attachment 60137 [details] test program by JOGL
Created attachment 60138 [details] test program by JOGL
SWT provides a thin glue between an open GL libraries (such as LWJGL and JOGL) and the operating system. Therefore, OpenGL should be running at native speed because we don't do anything. If this is not true, we need to fix it. Grant, can you please recreate the problem and take a quick look at it with Silenio to make sure we are not getting in the way?
(In reply to comment #4) > Grant, can you please recreate the problem and take a quick look at it with > Silenio to make sure we are not getting in the way? Sorry, I cannot understand what I should do for you. Could you explain more in detail ?
Now I understand you are asking Grant (^^) Please ignore my latest comment.
Can you confirm that the performance of a C program that makes the same OpenGL calls is faster than the equivalent SWT one?
Created attachment 60302 [details] test program with GLUT for Windows VC++ test program with GLUT for Windows VC++
Created attachment 60303 [details] test program with GLUT for Linux test program with GLUT for Linux
Created attachment 60304 [details] test program with JOGL test program with JOGL
Created attachment 60305 [details] test program with LWJGL test program with LWJGL
(Please ignore my previous benchmark result. I unchecked "Vertical Sync" at the graphic driver's settings, and now I can overcome 60 FPS.) My new benchmark result is as follows (unit is FPS): ----------------------+---------+--------- | Windows | Linux -------+--------------+---------+--------- C++ | GLUT | 2700 | 3200 Java | SWT + JOGL | 1400 | 2400 Java | SWT + LWJGL | 1400 | 2400 -------+--------------+---------+--------- I attached following 4 files used in the above benchmark. - glut_windows.cc: with GLUT for Windows VC++ - glut_linux.cc: with GLUT for Linux - SWT_JOGL.java : with JOGL - SWT_LWJGL: with LWJGL Could you reduce the difference between C++ and Java for both platforms ?
How does this compares with the experimental SWT OpenGL bindings? (See http://www.eclipse.org/swt/opengl/) For the purposes of comparison, could you recode your example to use that?
OK. I will recode next week.
Created attachment 60522 [details] test program with org.eclipse.opengl
I tried org.eclipse.opengl and here is the result. ----------------------------------+---------+--------- | Windows | Linux -------+--------------------------+---------+--------- C++ | GLUT | 2700 | 3200 Java | SWT + JOGL | 1400 | 2400 Java | SWT + LWJGL | 1400 | 2400 Java | SWT + org.eclipse.opengl | 1400 | ? -------+--------------------------+---------+--------- I could not try org.eclipse.opengl on Linux since I use x86_64 and could not find 64-bit version of libgl-0500.so.
Felipe, want to have a quick look at this mystery? Could it be the JNI overhead in Java vs C++?
Was part of the problem on Windows caused by the just fixed bug 182810?
Looking at the source code for the test programs I think it is quite possible that the recent fix to bug #182810 will narrow the gap between Windows and Linux that is reported in this bug. Both the LWJGL and JOGL test programs attached to this bug call canvas.setCurrent() in handleEvent. In a single context scenario like these test programs, setCurrent() tries to early-out when it detects that the call to setCurrent() was not necessary. However, (as reported in bug #182810) this detection was not working on Windows, forcing every call to setCurrent() to perform the time-consuming portions of that method. supertat, it would be great if you could grab the build that contains the fix reported in #182810 (20070418), run your test programs again on the same machines, and report the results here. We suspect there may be other sources of slowness on the Windows platform but it would be great to see how close the fix to 182810 gets us.
Jeff, I haven't tried the build yet, but as you suggested in bug #182810, I tried commenting out "canvas.setCurrent();" at display.asyncExec() and confirmed performance on Windows has improved from 1400 to 1800 FPS. On Linux, no effect. ----------------------------------+---------+--------- | Windows | Linux -------+--------------------------+---------+--------- C++ | GLUT | 2700 | 3200 Java | SWT + JOGL | 1800 | 2400 Java | SWT + LWJGL | 1800 | 2400 Java | SWT + org.eclipse.opengl | 1800 | ? -------+--------------------------+---------+---------
Java is still slower than C for no good reason. Could the glutIdle() function run more often than asyncExec()? Can someone test this hypothesis?
There's definitely a big difference between the way that the Java examples and the C examples are painting their FPS. One idea would be to just move the fps printing into the display function in the C++ program and see if that changes anything.
What?? I really didn't look at the test code. Are you telling me that the OpenGL code is not line for line the same in the C and Java? If this is the case, then the comparison might be quite bogus. Jeff, want to investigate? It's the end game of Eclipse 3.3 and I don't have any time to look into it. If we are in fact slower that C code for some reason, I want to know. Please use the experimental SWT OpenGL support in org.eclipse.opengl. It's not great, but I know that all that binding does it make OpenGL calls directly to C. It can't get faster.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
