Four views issue

OpenGL Development JOGL Development
#1

Hi everybody, I am developing a 3D modeling application in JOGL and I would like to have those typical 3DSMAX-like four views of one scene. It means, that those views should be resizable separate components. I solved this about a year ago with four GLCanvases. I just created four drawables with four shared opengl contexts among which I have to switch when drawing the scene. The rendering works fine, but it is extremely slow because of all the context switching. Rendering four views like this is probably a bad idea so I am asking, is there a way of making four separate canvasis render the same scene from different views without need to use mutliple contexts or without cycllng through them all the time?

Note: I use active rendering (drawing the scene only when its absolutely necessary).

From me question you probably deduced that I am not very experienced in using JOGL. Well it is true so feel free to point out any of my bad assumptions I made of JOGL, OpenGL or using OpenGL contexts. Thank you for helping.

#2

I’m not sure but maybe this will help?
http://fivedots.coe.psu.ac.th/~ad/jg2/jogl4/index.html

#3

I never done this myself, but are you sure that the context switching is the bottleneck? Did you profile it?

Other than that, how do you share your contexts? How do you render the scene? If you don’t already do it, you should perhaps compile the scene in a display list in the first canvas and only do glCallList in the other ones.

#4

If they don’t have to be in a separate window, you could split the main window into 4 viewports, using the glViewport() command. For each of these viewports, you setup the desired projection and modelview matrices and then render the scene. It may also be useful to use scissor testing to make sure no pixels from one viewport bleed into a neighboring viewport.

This is a suggestion, but as cylab pointed out, context switching is likely not the bottleneck since you’re rendering 4X as many things as usual.

#5

The application that I work on uses as many as nine GLCanvas objects on screen at once, and there’s no noticeable slowdown (except when initially creating or resizing).

#6

Thank you all for helping me. However what I really need is really four separate components, spliting with glViewport is not an option for me. In order to discuss some real piece of code I developed tiny demonstration example of my problem. To this post I attached two JAVA classes very easy to compile with latest release of JOGL. Only change the .TXT extension to .JAVA. It arranges four GLCanvases by JSplitPanes the same way my application does. When you move the cursor the bottom right corner of the black rectangle should follow the cursor. I always code under Linux and on my Ubuntu this example works just great without any noticable slowdown. But on windows (on computers at university lab which are actually much faster then mine) the performance is really horrific. I dont understand whether this is some kind of driver issue or the JOGL implementation for windows differs so much from linux implementation. Anyone has any idea?

#7

Did you try specifying “-Dsun.java2d.noddraw=true -Dsun.awt.noerasebackground=true”?

Edit:
I tried your code and it works like a charm for me - even without the mentioned commandline arguments. I am on Vista with the latest JOGL version. No Slowdowns or whatever.

It might not be the best idea to call display() in the mouselistener (it might be called more often that the refresh rate of your screen and display() blocks until it is finished), but since normally display() will block the EDT anyway, it is sufficient.

#8

Ok, I tried passing those extra -D parameters to the JVM which I have forgoten before but it makes no change at all. Still terribly slow. I really dont know who should I ask what to read or where to look for help. I did a little profiling (even though I am not too familiar with NetBeans profiler) so here is a screenshot of the profiler output after like 3 seconds of mouse moving over canvas[3].

#9

You seem to loose a lot of time in the canvas.display() call (with synchronizing with the OpenGL-Thread!?), but this shouldn’t happen. What card do you have and what drivers?

#10

could you put openGL.setSwapInterval(0); in the init method of the Renderer and try again? Maybe your test system has vsync enabled by default. This would kill your framerate since gl drawables swap buffers automatically after display() was called on all listeners.
In other words you would only draw one canvas per screen refresh - all others would wait on display().

I tested it with your classes and it significantly slowed down with enabled vsync (not only FPS*0.25 it was for some reason very inconsistent)

#11

Oh my god, oh my god, it WORKS!! Thank you guys so much for helping me with this. You saved me from killing myself by smashing my head aginst the monitor.

#12

Good catch! :slight_smile: