GLJPanel: What's wrong?

OpenGL Development JOGL Development
#1

Here the code


GLJPanel panel = new JGLPanel();
GLContext context = panel.createContext(null);

and the exception


Exception in thread "main" java.lang.NullPointerException
	at javax.media.opengl.GLJPanel.createContext(GLJPanel.java:748)
	at Main.main(Main.java:12)

Does someone have a suggestion??

#2

You are not supposed to call createContext with a ‘null’ argument, hence the NullPointerException.

#3

Hmm, actually my statement seems to be untrue after reviewing the javadoc of GLJPanel

What are you trying to achieve?

#4

From http://download.java.net/media/jogl/builds/nightly/javadoc_public/javax/media/opengl/GLDrawable.html#createContext(javax.media.opengl.GLContext)
[i]
public GLContext createContext(GLContext shareWith)

Creates a new context for drawing to this drawable that will optionally share display lists and other server-side OpenGL objects with the specified GLContext.

The GLContext share need not be associated with this GLDrawable and [b]may be null if sharing of display lists and other objects is not desired[/b]. See the note in the overview documentation on context sharing. [/i]
#5

I’m doing some experiments with JOGL. I’m trying to build my own rendering loop.
I know that i will meet a lot of problem, but it’s a way to understand how JOGL works under the surface.
The thing that really surprised me is that behaviour is not compliant with the specification.

So i’m guessing if i’m doing something wrong… but in two lines of code there’s not enough space to put errors 8)

#6

Hmm, maybe you should just take a look into the GLJPanel then and see what’s at the reported line.

#7

Just to make sure, did you mean GLJPanel panel = new GLJPanel() and this was just a typo?

#8

Ehmm… sorry :-[

GLJPanel panel = new GLJPanel() is the right :wink:

#9

I did some investigating in GLJPanel’s source code and the createContext method is this:

 public GLContext createContext(GLContext shareWith) {
    if (!hardwareAccelerationDisabled) {
      return pbuffer.createContext(shareWith);
    } else {
      return offscreenDrawable.createContext(shareWith);
    }
  }

So I’m assuming that either pbuffer or offscreenDrawable is null. These won’t become initialized until the GLJPanel has become fully visible and initialized as well. I was able to call:

public void init(GLAutoDrawable ad) {
   GLContext context = ad.createContext(null);
}

without errors.
Maybe the javadoc should be edited to let users know of this caveat?

#10

I can say that I’m able to create a context from a GLCanvas without the implementation of the GLEventListener interface.

This code is called inside the constructor of a java.awt.Canvas:


context = GLDrawableFactory.getFactory().getGLDrawable(this, null, null).createContext(null);

Moreover the createContext fucntion is inside the interface GLDrawable, so I aspect every GLDrawable to behave the same way.

#11

The GLJPanel currently works differently than the GLCanvas; it needs to be rendered to at least once before you can call certain operations on it. You can feel free to file a bug, but it’s going to be a while before we can look into it. Contributions would be welcome.

#12

Ok.
A last question: so JOGL is not yet JSR 231 fully compliant?

#13

I’m with a question around my mind and maybe some of you could help me: is perfomance the only problem of GLJPanel comparing to GLCanvas? Let’s suppose I have a 10,0 GHz processor, 3 GB RAM and a 1 GB RAM graphics card. This would solve the problem?

That’s because I guess there is a conflict in Swing beeing THE GUI toolkit in Java but I cannot use (with full performance) an all swing solution in JOGL!

#14

GLJPanel documentation (taken from the javadoc nightly build):

A lightweight Swing component which provides OpenGL rendering support. Provided for compatibility with Swing user interfaces when adding a heavyweight doesn't work either because of Z-ordering or LayoutManager problems.

The GLJPanel can be made transparent by creating it with a GLCapabilities object with alpha bits specified and calling setOpaque(boolean)(false). Pixels with resulting OpenGL alpha values less than 1.0 will be overlaid on any underlying Swing rendering.

Notes specific to the Reference Implementation: This component attempts to use hardware-accelerated rendering via pbuffers and falls back on to software rendering if problems occur. Note that because this component attempts to use pbuffers for rendering, and because pbuffers can not be resized, somewhat surprising behavior may occur during resize operations; the GLEventListener.init(javax.media.opengl.GLAutoDrawable) method may be called multiple times as the pbuffer is resized to be able to cover the size of the GLJPanel. This behavior is correct, as the textures and display lists for the GLJPanel will have been lost during the resize operation. The application should attempt to make its GLEventListener.init() methods as side-effect-free as possible.

GLCanvas documentation (taken from javadoc nightly build):

A heavyweight AWT component which provides OpenGL rendering support. This is the primary implementation of GLDrawable; GLJPanel is provided for compatibility with Swing user interfaces when adding a heavyweight doesn't work either because of Z-ordering or LayoutManager problems.

From experience I can say that GLCanvas offers the most performance (at least for me) if you are using pure opengl commands. If you want to mix java2d and opengl you’re better off using gljpanel as it can be accelerated(needs a special parameter to the vm and doesn’t work on all systems yet, also not on mine sadly). For more information about that read this link: http://weblogs.java.net/blog/campbell/archive/2006/10/easy_2d3d_mixin.html.

Oh yeah and if you don’t have a decent opengl driver installed you won’t get much performance either, because it’ll always use software rendering.