JOGL 1.1.1a crashing if using multiple AWT Frames (windows)

Hi, this is my second thread on the forums, and I am still a little new to JOGL :).
I discovered some odd crashes in my JOGL program, it was freezing when adding a lot of windows.

I found it had nothing to do with my program: The same thing happens with the following standard program:



package joglscreens;

import java.awt.Frame;
import javax.media.opengl.GLCanvas;

public class MainWindow extends javax.swing.JFrame {

    public MainWindow() {
        initComponents();
    }

    @SuppressWarnings("unchecked")
    private void initComponents() {
       ...*auto generated code for the window*...
    }             

    private void jButton2ActionPerformed(java.awt.event.ActionEvent evt) {                                         
        Frame F = new Frame();
        F.setSize(400, 400);
        F.add(new GLCanvas());
        F.setVisible(true);
    }                                        

    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new MainWindow().setVisible(true);
            }
        });
    }

    private javax.swing.JButton jButton2; 

}


This program is a small window with 1 button, every time it is pressed it creates a new AWT frame and adds a GLCanvas to it.
Once you reach much above 50-60 windows, the entire program freezes without reason. Doesnt matter if I add more memory
with Xms… or Xmx… VM arguments, it freezes without any error message.
If I remove the GLCanvas from the window I can add hundreds of AWT windows no freezes.

http://yoda.reservoirselite.com/joglBug.png

I have the same problem on WinXp32, Win7-32 and Win7-64 ( I dont have other OSs installed atm )
I have tested with GTX260, HD4870 and Radeon X1600 mobile with the same results.
I am using the latest official sun JVM, and I’ve tried both 32 and 64bit JREs with the same result

thats interesting. Thank you very much for testing with different hardware and systems. I should really take a look at that but i have so many other things on the TODO list :confused:

since you are on windows you probably started with -Dsun.java2d.nodraw=true right :wink: (if not you should)

Have you noticed anything else if it freezes?
e.g Peak in CPU usage.
If you start another testcase when the first freezes does the second one work at all or does it freeze immediately too?

if nothing above applies its probably a deadlock.

I ran the debugger on it one of the threads ( I cannot remember which ) seems to be stuck on
object.wait, which to me sounds like a deadlock. CPU uage is quite low, all the
way up to the freeze, where it jumps dramatically and gets stuck at 50%. ( 1 of 2 CPU cores )
When it freezes, EVERYTHING freezes in the entire app ( all screens ).

“-Dsun.java2d.nodraw=true” as VM arg made no difference

2 test cases simultaneously

I started 2 tests simultaneously and I clicked the first one up to about 80 screens before it froze.
Then i started adding screens to program #2 ( which froze after just 2 screens )

Maybe you’re simply running out of native resources. I personally don’t see the point of creating 80 windows, each with its own GL context.

When rendering things to the GLCanvases the limits go down by quita a lot, and on my laptop Ive seen it happen already at 5-10 displays.
And this is when im only rendering small graphics similar to this : http://www.youtube.com/user/MrTheGurra#p/a/u/0/b0Ge86XCkx4

Riven is almost certainly right. Since its not a deadlock (high cpu usage) its probably a native resource issue. Keep in mind that the default constructonr of GLCanvas will create a new OpenGL context for each component. Consumer GPUs are not build for that requirement.

You could inject the composeable debug pipeline (drawable.setGL(new DebugGL(drawable.getGL()))) - maybe you get some error codes.

Ok, sounds reasonable.
Are there any important thread safety considerations that I must take into account if I instead create only 1 context
that I share among my components?

Update:
Is there documents available showing how to create only a single context shared between multiple components?
I assume the code below only shares data between 2 contexts and does not actually use thesame context. ( because it crashes too :))


    private void jButton2ActionPerformed(java.awt.event.ActionEvent evt) {                                         
        Frame F = new Frame();
        F.setSize(400, 400);
        GLCanvas canvas = new GLCanvas(null, null, context, null);
        F.add(canvas);
        F.setVisible(true);
    }

What are you trying to achieve? Do you actually need it?

Even 5 windows/contexts/framebuffers are more than just about every application would need.

I am building a home cockpit for flight sim games entirely rendered on monitors/lcds.
For this purpose I must be able to draw a very large number of displays in real time, currently
I render between 30-100 fps on each display. ( the actual non-jogl parts of my program can
actually handle several thousand fps )

I can already do the data processing and graphics generation fast enough, the only thing
missing right now is the ability to have enough screens up.

Here is an example of a user with just 2 extra monitors as MFDs ( Multi Function Displays). http://www.youtube.com/watch?v=7H3S1GTro0E&feature=player_embedded
This will later be extended to also include analog instruments etc.

My display computer will prob have 3-4 graphics cards with 2-3 outputs each as a start.
Also some of the displays will run multiple instrument windows. ( 34n… a lot! :slight_smile: )

The purpose of using OpenGL for this was to minimize abstraction layers and not use too much computing power,
my thought being “if this can handle heavy 3d graphics then the small things I throw it should be a piece of cake”.
I liked the idea of doing it from java since it cuts my development time by 90% or so compared to me coding in c++

I have already made a similar project in C++ & Direct3D but switched to Java because of the massively
faster development times ( for my capabilities! )

Interesting. Can you manage to create more similair windows in OpenGL in C++? If so, we at least determined that it’s a JOGL problem.

Right now I don’t have such development tools installed, I will see if I have some old binary of my C++ project and start some displays.

My c++ & D3D9 easily manages well above 100 displays using similar code and the same graphics shapes.
I didnt want to click “add display” more times than 116 times ( my finger got tired ) here in the picture below :).
But I think I could have put up several hundred displays no problem. I was only seeing about 150 MB ram use at
116 displays and almost 0 CPU usage.

http://yoda.reservoirselite.com/screens.png

What frustrates me is not that the java+OpenGL variant cannot handle more than 10 displays.
The problem is that sometimes on my laptop it would crash after 5, sometimes 10, and this inconsistency makes
it very hard to release a software with. ( even as free open source, which all my projects are )

maybe someone of the LWJGL guys could port the testcase and try it out?

without being able to tell from my experience i expect that rendering with OpenGL in large amounts of independent windows will probably be overkill for consumer GPUs. You could try to render in one huge framebuffer and distribute the fragments to the displays and draw the image again in software mode if everything else fails.

I believe JOGL 1 calls swapBuffers after each display() which causes a gl.flush() of finish() I don’t know how good the drivers can deal with contention at this point.

That may not be a bad idea. The question is…how on earth would I do such a thing? =).
I know very little about OpenGL or D3D programming, what I know I’ve learned as I’ve tried
different things ( like these projects ).

If I interpret you correct, you want me to render just 1 HUGE ‘picture’ ( I dont know the exact definition of a frame buffer ),
and then cut it up and distribute to the displays?
I think it is a good idea, question is …how to do it. Can JOGL do this, or will JOGL
let me access the required raw data? Will this kind of rendering be efficient or require a lot of extra CPU resources?
Will it let me run each display 30-50fps simultaneously? =)

To try the test case in LWJGL should only require them to change 1 line ( From GLCanvas of JOGL to the type they have in LWJGL)
Remember the test case does not actually render anything. No gleventlistener is used or anything like that. It just creates a canvas object.

Off topic

LWJGL has addressed the OpenGL issues with ATi Catalyst 10.x here : http://lwjgl.org/forum/index.php?topic=3212
Will JOGL do the same ? ( My JOGL applications crash with catalyst 10.x but work perfect in 9.12)

i did a quick test with my build of JOGL 2 and opened 200 windows in a loop without any issues. After initialization, repaints etc worked flawlessly without any noticable increase of the cpu load.

(system was linux, the only anomaly was a short flicker of compiz, after switching desktop effects off well… nothing exciting happened)

don’t know maybe its automatically fixed with JOGL 2 it looks like its related to the context creation changes required for GL 3? If yes than this is not in jogl 1.1.1 thats correct.

(thats it for today… have to do other things now)

So it looks like all issues are solved in JOGL 2 .
Do you think you could post the code for your JOGL 2 test?
I will check out jogl2 soon, thank you very much for all the help!

( also thanks for the help with JOCL, I posted a few things on kenai a while back :))

Are there any programming samples for Jogl 2 available?

there are over 100 ready to run jogl2 samples in the beta version of the NOGL Pack. (NEHE+redbook+jogl demos)
it uses however an older beta build of jogl2
(kenai is currently down… you can find it in the early access download section)