[SOLVED] Problem Moving from 1.1.1a -> 2.0

Hi all,

I inherited a geology visualization project running against JOGL 1.1.1a.  Various drawing issues prompted me to give JOGL 2 a try, and to my great joy, it fixed nearly all of them!  However, it also introduced a new problem that has me puzzled.  The software is intended for use on multiple displays to provide a larger workspace (sediment cores can be very long).  As implemented, each display is assigned a GLCanvas embedded in a JFrame.  All canvases are constructed with a common GLContext in order to share textures, display lists, etc.  The first instantiated canvas works perfectly, but subsequent canvases exhibit two problems:

1. Primitives draw in black regardless of the most recent glColor() call
2. Text rendering, which is all display-list based, doesn't work at all

This worked correctly in 1.1.1a.  That said, I'm quite sure this is my problem, not JOGL's!  I've confirmed that the canvases are using the same GLContext, and repeated checks of glGetError() yield nothing.  It's been a whlie since I"ve worked with OpenGL, but some of the code looks a bit sloppy as far as consistent enabling/disabling of features, etc: is JOGL2 pickier about such things than 1.1.1a?  Another wrinkle that may be a factor: all rendering takes place in JNI calls rather than Java.

Does this issue sound familiar to anyone? Perhaps I overlooked something in the transition to 2.0?

Any ideas/suggestions would be greatly appreciated!

Hi

I used JOGL 2.0 in a geology visualization project too like several people here.

Which hardware do you use? Do you reproduce this behaviour on all machines?

I've seen this on three different machines:

My Win7 dev machine: Geforce 7900 GTX, drivers appear to be up-to-date
My MacBook Pro: Geforce 9400M
Multi-screen setup in the lab I work for, which runs XP.  Not sure of the hardware, but I believe it's an NVidia card as well.

I should also mention that a multi-display setup isn't required to see the problem, multiple canvases resized to fit on a single display still show the issue.

gouessej wrote

I used JOGL 2.0 in a geology visualization project too like several people here.

Really? Small world! Anything I'd be familiar with?

How do you share the context? I had the same problem when trying to implement a full screen toggle. NEWT seems better to do that.

I work on this:
http://www.openflowsuite.com

Okay, it's definitely a context problem.  We attempt to share contexts as follows:

1. Create a dummy GLCanvas with the default constructor
2. Grab that canvas's GLContext with getContext()
3. Pass that context when instantiating the GLCanvases we actually render to

I discovered this thread and tried his workaround - after creating the dummy canvas, add it to a Frame and make the frame visible - it works!!!  I'm delighted, but why do I need the workaround?  That thread is from late 2010, and his last post suggests the issue was resolved in a newer JOGL build ("cool, it works fine now with the jogl-2.0-b3-20101124-windows-i586 build").  Is my approach to sharing the context the problem?  How should I be doing it?

On 03/16/2012 07:59 AM, sorghumking [via jogamp] wrote: Use the source 'sorghumking' :)

http://jogamp.org/git/?p=jogl.git;a=tree;f=src/test/com/jogamp/opengl/test/junit/jogl/acore;h=36a0b271b26633906c1d1395d33545632d774c7e;hb=HEAD

Looks at the many tests here w/ *SharedContext* in the name.

~Sven

Hi

No, your approach is fine but maybe there is a smarter way to do it. It's possible to create an OpenGL context representing the one used by an external OpenGL-based library but I don't remeber whether it is possible to create a separate OpenGL context without creating any drawable. I should have a look at the source code of my JOGL renderer of Ardor3D to answer you more accurately. Anyway, it would be better to retrieve the context from the first really useful GLCanvas you create but this context will be destroyed if your GLCanvas is removed from its container (but not if you use a GLWindow).

In JOGL 2.0 (unlike JOGL 1), the context becomes available in addNotify(). Therefore, if you don't add your GLCanvas to any container, you'll have some problems... When I ported Ardor3D to JOGL 2.0, I had forgotten this change (my bad, I should sleep much more) and I simply had obtained some NPE for a long time.

Is it possible to do this without using a PBuffer?

On 03/16/2012 10:18 AM, gouessej [via jogamp] wrote:
>
>
> Is it possible to do this without using a PBuffer?
>

even though the example is using one dedicated 'root' offscreen
context .. the spec doesn't hinder you of using an onscreen context.

however, experience w/ shared context tells my that YMMV,
ie. sometimes it just crashes. This might be due to driver difficulties
since shared context's are not really what folks use today in games, AFAIK.

~Sven

Yes, it is not useful in games almost always running into a single window. I experienced crashes on some machines both when sharing offscreen context and onscreen context. It is really difficult to rely on the share of context. Fortunately, NEWT has been helpful to prevent the destruction of the context when removing an OpenGL canvas from its container, it allows to avoid using shared contexts in some cases.

I've got it working without a dummy canvas now, hooray!

Sven and Julien, many thanks for your patient advice. Now that I realize its power, I will actively Use the Source!  (Though you're both Yoda to my young padawan.)