GLCanvas fullscreen horror

OpenGL Development JOGL Development
#1

Hello everyone,

this is kind of a newbie thread, but not really. I’m a C++ dude, and have just been assigned to learn Java, and expect to be using it heavily for the next 2 years. It’s a nice compliment to C++ in many ways. I’m 3 weeks into getting set up with things.

OK, here’s my worries. I’m developing a project that requires 2/3 screen to an openGL window, the other 1/3 to user input / text / data manipulation. I’m getting up to speed with swing, so the 1/3 part will be fine. I’m using jogl, and its all working. My opengl experience is also good.

But I have been researching getting hardware acceleration for jogl ( I will need it ), and I read that the only way to enable hardware is to go fullscreen. Before I go and hit a wall for a few weeks, thought I would ask for advice here. I already found that using a JFrame as my main app window, and using a GLCanvas on the left 2/3 view, my JMenu abilites get wiped out due to heavyweight occlusion. So switching to AWT menu… it works. But how do you guys get around this?

Also, if I go fullscreen with a GLCanvas, then I surely lose the opportunity to add Swing containers to the right 1/3? A big attraction for Java is the cross platform GUI stuff, and I just want to get on with my app, rather than rewrite a GUI. I thought that one way would be to make a thread for the canvas, and a thread for the swing.

Sorry for the long post! Help the poor C++ dude! thanks :slight_smile:

#2

[quote]I’m a C++ dude, and have just been assigned to learn Java, and expect to be using it heavily for the next 2 years. It’s a nice compliment to C++ in many ways.
[/quote]
Nice to see you :slight_smile:

[quote]But I have been researching getting hardware acceleration for jogl ( I will need it ), and I read that the only way to enable hardware is to go fullscreen.
[/quote]
Hum where did you read that ? It seems pretty strange to me because I can run some high OpenGL effects using JoGL in windowed mode, which could only be possible with a good graphic card… From what I’ve seen, I’m sure JoGL use hardware in windowed and fullscreen mode. OpenGL is used in the native part and this part is the same using windowed of fullscreen mode so…

#3

You can go full screen with a jframe and keep your 1/3 swing available as long as it doesn’t overlap with the glcanvas (i’ve done it for the 3D model and map editors of zoltar’s return)

Lilian

#4

First of all, it’s nice to hear that you’ve had a nice Java experience so far :).

You are not limited to fullscreen GLCanvas, when speaking of hardware accelerated OpenGL functions. Just create the GLCanvas instance by defining hardware accelerated GLCapabilities:

GLCapabilities glCaps = new GLCapabilities();
glCaps.setHardwareAccelerated(true);
// Set other capabilities here…

GLCanvas glCanvas = GLDrawableFactory.createGLCanvas(glCaps);

You can alter Swing menus to use heavyweight representation globally (no more overlapping of menu and GL canvas components) by using the following piece of code:

JPopupMenu.setDefaultLightWeightPopupEnabled(false);

Cheers

#5

Thanks all for being so friendly and helpful. That certainly puts my mind at ease concerning jogl + hardware. I did read the fullscreen point somewhere ( and it seemed pretty well informed, but could have been old ), and sorry I don’t have a link for it. I’ve been reading a lot the last few days!

@nnevatie : thanks! That was exactly what I was looking for regarding the menu. Now, you would think that the function setDefaultLightWeightPopupEnabled() would exist for all swing components, but does that imply they are casted to awt style objects? Hence, breaking swing.

Here’s a question for you guys. I’ve got left 2/3 as a GLCanvas, the right 1/3 as swing. Is it possible for me to have a swing container appear in the middle of my app, via blending ( alpha 0.0 -> 1.0 ), covering my GLCanvas? I think not, as any swing component would be occluded. But if I use an awt window instead, I can’t do the blending. Any possibility here?

#6

I believe the hardware acceleration was an issue with java and not specific to JOGL, so if you wrote a java2d game it wouldn’t be accelerated without being in fullscreen mode.

You’ll probably have to write your own windowing code if you want an overlapping window to be transparent through to your GLCanvas, I might be wrong about this. You should in theory be able to create this effect by creating screenshot of your glcanvas and using it as a background image in your overlapping window but this would be pretty slow (if nothing change in your scene then it wouldn’t be too bad but if you want an actively updating scene to show through you’d have to create your own windowing code).

#7

Old video cards, and I am talking 6 or 7 year old cards, used to only be able to accelerate fullscreen apps. This has not been the case for a long time. Java2D, as long as you create images correctly, and Jogl, GLCanvas only at the moment, will be accelerated in a window. Currently I don’t think you will be able to blend a container on top of a GLCanvas. Perhaps when we have a working implementation of GLJPanel you will be able to do it.

#8

Thanks for the feedback. well, that’s a pretty heavy restriction, but I guess that’s that. Don’t know how you java dudes deal with it! Hehe, well, I’ll be learning too I guess.

Thanks again for all the help so far.

#9

[quote]Now, you would think that the function setDefaultLightWeightPopupEnabled() would exist for all swing components, but does that imply they are casted to awt style objects? Hence, breaking swing.
[/quote]
The reason the popup menu has the lightweight option, is because it has a tendency to ‘pop-up’ over other components. (This is true of drop-down lists/combo-boxes/menus, too). If it might appear over heavyweight components, then set the lightweight enabled option to false. Otherwise the default of true is fine.

Hope that helps…

#10

Don’t even bother with using GLJPanel as it doesn’t provide any benefits, only negatives. Provided you’re not doing tabbed interface (it doesn’t sound like it) , then the normal GLPanel plays nicely with Swing. As the others have already noted, there’s a few small API calls that you’ll need to make if you’re going to play with menus over the 3D area, but that’s about it. We’ve been using JOGL and Java3D in this way for years in Swing apps and not had any problems at all.

Apart from the beta-ish nature of JOGL (some function calls are not yet mapped), and the one change to how pBuffers are handled, all your existing OpenGL experience will transfer across perfectly. You’ll also want to dig into your book of tricks regarding performance optimisation too as you have one extra set of overheads to deal with - JNI. All those Java calls have to end up as calls to the local OGL libs. JNI is not exactly the fastest thing in the world (lots and lots of synchronisation overheads). So, don’t plan on doing thousands of glVertex() calls, stick to the fast options like vertex arrays/objects etc.

As a rough comparison, if you do things optimally, then there should be no speed difference at all between a native and Java app that use OpenGL. In our small application space of X3D/VRML rendering, our Java + JOGL code has at least twice the framerate of every other competitor - almost all of them coded in C or C++. I think that says more about their coding abilities more than anything else as there should be no valid reason why there is such a huge performance difference.

#11

Thanks for the input Mith, I’ve been away and just saw your post.