GLCanvas in CardLayout

Just upgraded a 30K SLOC app to JOGL 2. Works great on 32-bit Vista, NVIDIA graphics.  Bad news with 64-bit Win 7, Intel .

Need help!

Description:
FPSAnimator driving a GLCanvas in a CardLayout with JPanels.  Initially one of the JPanels is showing.  A button press makes the GLCanvas visible. Another button switches to a JPanel.  

This used to work fine in JOGL 1.1.1 .

First time selected, the GLCanvas animation works great.  When you flip to a JPanel and then back, the screen is completely dead.  display() is being called but no image.

No exceptions or errors with DebugGL2, -Djogl.debug=true -Djogl.verbose=true .

Pared down example is below.  Am I doing something wrong?

Details of the failing setup:

JOGL:
This is build version 2.0-b41-20110916, based on:
              branch  rc
              commit  64feda2fa7611627e31f55ecc7cf86e290fdf4e3

Hardware:
Intel HD Graphics
Driver 8.15.10.2559 (most recent)  An earlier driver had the same problem.
HP G72 Core i3 N50 2.27GHz 2 cores

OS: Win 7 Home Premium SP1 Build 7601, current patches

// Small example with the problem described above.
import com.jogamp.opengl.util.FPSAnimator;
import java.awt.*;
import java.awt.event.*;
import javax.media.opengl.*;
import javax.media.opengl.awt.GLCanvas;
import javax.swing.*;

public class Test extends JFrame implements GLEventListener {
   private CardLayout cards;
   private static final String LABEL = "label";
   private static final String CANVAS = "canvas";
   private String selected = LABEL;

   public Test() {
      GLProfile glp = GLProfile.get(GLProfile.GL2);
      GLCapabilities caps = new GLCapabilities(glp);
      GLCanvas canvas = new GLCanvas(caps);
      canvas.setPreferredSize(new Dimension(640, 480));
      canvas.addGLEventListener(this);
      final FPSAnimator animator = new FPSAnimator(canvas, 60);
      addWindowListener(new WindowAdapter() {
         public void windowClosing(WindowEvent e) {
            new Thread() {
               public void run() {
                  animator.stop();
                  System.exit(0);
               }
            }.start();
         }
      });
      JButton button = new JButton("Switch Cards");
      add(button, BorderLayout.NORTH);
      final JPanel cardHolder = new JPanel();
      cards = new CardLayout();
      cardHolder.setLayout(cards);
      cardHolder.add(new JLabel("A label to cover the canvas"), LABEL);
      cardHolder.add(canvas, CANVAS);
      add(cardHolder, BorderLayout.CENTER);
      button.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
                if (selected.equals(LABEL)) {
                    animator.start();
                    cards.show(cardHolder, CANVAS);
                    selected = CANVAS;
                }
                else {
                    animator.stop();
                    cards.show(cardHolder, LABEL);
                    selected = LABEL;
                }
            }
        });
      pack();
      setTitle("OpenGL 2 Test");
      setVisible(true);
   }

   public static void main(String[] args) {
      new Test();
   }

   public void init(GLAutoDrawable drawable) {
     GL2 gl = drawable.getGL().getGL2();
     gl.glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
   }

   float spin = 0;

   public void display(GLAutoDrawable drawable) {
     GL2 gl = drawable.getGL().getGL2();
     gl.glClear(GL2.GL_COLOR_BUFFER_BIT);
     gl.glPushMatrix();
     gl.glRotatef(spin, 0.0f, 0.0f, 1.0f);
     gl.glColor3f(1.0f, 1.0f, 1.0f);
     gl.glRectf(-25.0f, -25.0f, 25.0f, 25.0f);
     gl.glPopMatrix();
     gl.glFlush();
     spin += 1;
     while (spin > 360) spin -= 360;
   }

   public void reshape(GLAutoDrawable drawable, int x, int y, int w, int h) {
     GL2 gl = drawable.getGL().getGL2();
     gl.glViewport(0, 0, w, h);
     gl.glMatrixMode(GL2.GL_PROJECTION);
     gl.glLoadIdentity();
     if (w <= h) gl.glOrtho(-50.0, 50.0,
         -50.0 * (float) h / (float) w,
         50.0 * (float) h / (float) w,
         -1.0, 1.0);
     else gl.glOrtho(-50.0 * (float) w / (float) h,
         50.0 * (float) w / (float) h, -50.0, 50.0,
         -1.0, 1.0);
     gl.glMatrixMode(GL2.GL_MODELVIEW);
     gl.glLoadIdentity();
   }

   public void dispose(GLAutoDrawable drawable) { }
}

Hi

Please do the same with those flags:
-Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all

Intel is known for its bad hardware. Are you absolutely sure that it was working with JOGL 1.1.1a and this hardware? I think that the context is destroyed whereas it shouldn't. Maybe use NewtCanvasAWT to work around this bug but I'm not sure it will work better.

Hi Gene,

I just tried your example on Win 7 64-bit with Nvidia graphics and it works fine (pressing the "Switch cards" button flips back and forth between the text label and a rotating square). This is with both an old version of JOGL 2 from August, and with the very latest dev build from today.

I don't have an Intel card, so I can't test the exact setup you have. However, JOGL 2 does call some WGL driver functions that JOGL 1 doesn't call, so if your Intel driver has some problem, it can affect JOGL 2 but not JOGL 1. Have you tried running other JOGL 2 test programs?

Thanks for the very quick response.

I'm sure.  I have all 3 running on the same machine right now: JOGL 1.1.1a version, JOGL 2 version, and the pared down example.  One works.  The other two fail.

I ran the debug  options you gave.  Output is at http://kenai.com/downloads/wpbdc/debugOutput.txt  Sequence: Started the little app. Pressed the button twice.  Closed the window.

Believe me I know about Intel video problems, but I can't tell users of this app to pound sand.  If I can't get this fixed quickly, must roll back to 1.1.1a.

I appreciate the help very much.

Hi. Thanks again.

I just tried the Gears test applet and it fails.  The Java window is just black. No rendering going on. The f and r controls work, but no rendering.  After a while IE locks up.

Guess I'm doomed to roll back.

What new API calls are made?  Maybe I'll try to look at it.

Gene

On Friday, December 09, 2011 08:56:52 AM Gene [via jogamp] wrote:
That would be very much appreciated.

The new WGL API calls are almost all in:
http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/jogamp/opengl/windows/wgl/WindowsWGLContext.java;hb=HEAD#l179

The ARB ctx creation stuff supports the new GL profiles >= 3.1
and was not avail in JOGL 1.*

Can you also pls report your Intel GPU and driver version please ?

Maybe you can advise which Intel board/GPU would be best to buy
to finally fix support for those drivers ?
Or .. maybe you have a chance to give me ssh access on your intel windows box
(cygwin, users mode sshd to access the hardware accel. desktop).

~Sven

>
> Gene
>

Gene uses the latest driver for Intel HD Graphics and some Intel GMA used with Intel Core i3, i5 and i7.

Does this bug have a relationship with this one?
https://jogamp.org/bugzilla/show_bug.cgi?id=498

If he gives us some more information, maybe I can find a similar machine and give you a ssh access on it. Someone asked me to repair an Optiplex GX280 with an Intel chip, it might be helpful for the bug 498 but not for this one and Wade already tried to fix it.

Edit.: Gene wrote in the first post that he uses Intel HD Graphics.

Edit.2: HP G72 Core i3 uses Mobile Intel HM55 Express.

On Friday, December 09, 2011 01:06:18 PM gouessej [via jogamp] wrote:
ssh access would be awesome,
since kicking around builds and let them test by somebody else
really is hard to do .. at least I won't have that much patience :)
[Kudos to Wade, who has .. and nailed down one NV driver 'bug' (stack size)]

So yeah, bring it on - maybe we can fix it w/ your machine,
I hope so. It's always finding the neadle in the haystack,
since you just can't tell which API they have the bug in.

Q: Is this i7 thing the 'new' sandy bridge (SB) stuff ?
Maybe it makes sense to 'support' (test) at least SB, which may gain/have proper 3D accel.

Then the question arises whether to test their open source driver (linux)
or simply test JOGL w/ Mesa3D software only. The latter still lacks pbuffer
support AFAIK.

I know, it's getting complicated :)

~Sven

I think he uses something close to this:
http://www.intel.com/content/www/us/en/chipsets/mainstream-chipsets/mobile-chipset-hm55.html

The woman who asked me to repair the Optiplex GX280 owns a laptop with an Intel integrated chip using the same driver on Windows 7, I can ask her to help me in about 10 days but we would have a very little time to do it, maybe 2 hours in the best case.

Someone else has a similar problem here but with an NVidia graphics card:
http://www.ardor3d.com/forums/viewtopic.php?f=10&t=4300&p=13525#p13525

Hi Gene,

I can mail you a JOGL driver test that has every driver call instrumented and logged. That way we can see what the return values are for each driver call, and determine if there's something unusual about the way the Intel drivers behave. I would post the test here, but the zip is too big for the forum software to allow it.

If you don't want to post your email address on the forum (can't blame you), you can instead either register as a user on this forum, or enter a JOGL bugzilla bug for this issue, and I'll be able to mail you as an administrator. Just let me know how you'd like to proceed.

On Friday, December 09, 2011 01:46:27 PM gouessej [via jogamp] wrote:
>
> Someone else has a similar problem here but with an NVidia graphics card:
> http://www.ardor3d.com/forums/viewtopic.php?f=10&t=4300&p=13525#p13525
> http://www.ardor3d.com/forums/viewtopic.php?f=10&t=4300&p=13525#p13525 
>

I see, 'Sie sprechen Deutsch' - your German is very good.
My French is lousy and almost forgot all of it and had only a bit of a year in school
before I 'cancelled' it :( Now, I try to learn Chinese .. well, another attempt for failure :)

Ok .. back to the issue.

The exception thrown:

+++

Exception in thread "main" javax.media.opengl.GLException: Unable to create temp OpenGL context for device context 0x201206f
        at jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl(WindowsWGLContext.java:294)

+++

Is _after_ the SharedResourceRunner successfully established a GL 3.3 context and made it current.

Then your AWT Canvas 'thingy' attempts to create the context, where the ARB method fails
and the fallback:
  WindowsWGLContext.java:292 temp_ctx = WGL.wglCreateContext(drawable.getHandle());
fails as well.

My only conclusion here is that the native drawable handle is not valid,
probably it's not configured properly (HDC/PFD -> WindowsWGLGraphicsConfiguration.setPixelFormat(..)).
Please double check our 'validateGLDrawable()' usage as noted below.

Sorry that I have no time right now to review your 'JoglAwtCanvas' impl. but I hope these explanations
help to solve the problem, since IMHO this bug is not related to the OpenGL driver.
I may have time in one week to get my hands on it, well .. sorry.

Another thought is .. wouldn't it be possible to simple inherit from our GLCanvas ?
(Since it's impl. is proven so far .. and impl. the AWT 'hook' is a horrible task)

Here is what I have send to another person about JOGL's GLCanvas
and it's initialization sequence .. since it's very tricky - to say the least:

+++

addNotify() {
  drawable.lock() {
        awtConfig = chooseGraphicsConfiguration(capsReqUser, capsReqUser, chooser, device);
        if(null==awtConfig) {
            throw new GLException("Error: NULL AWTGraphicsConfiguration");
        }

        drawable = GLDrawableFactory.getFactory(capsReqUser.getGLProfile())
                           .createGLDrawable(NativeWindowFactory.getNativeWindow(this, awtConfig));
        context = (GLContextImpl) drawable.createContext(shareWith);

        ...

        // before native peer is valid: X11
        disableBackgroundErase();

        // issues getGraphicsConfiguration() and creates the native peer
        super.addNotify();

        // after native peer is valid: Windows
        disableBackgroundErase();
  } drawable.unlock();
}

The path of initialize the AWT GraphicsConfiguration along w/ the AWT NativeWindow (JAWTWindow)
is very sensitive to say the least.

Notes:

'validateGLDrawable()' issues 'drawable.setRealized(true)', ie updates and finalizes
the AbstractGraphicsConfiguration, eg. WindowsWGLGraphicsConfiguration - including the call
to WindowsWGLGraphicsConfiguration.setPixelFormat(..)!!

'validateGLDrawable()' is invoked in the AWT Canvas's display() method and only proceeds if
the AWT native peer size is > 0x0. Attempts to issue this at addNotify() may fail, since the
native peer (HDC) is not yet established completly (or something like that).


The call 'NativeWindowFactory.getNativeWindow(this, awtConfig)' generates a NativeWindow impl. JAWTWindow
wich is then used as the agnostic interface for the GLDrawable implementation.

The 'awtConfig' must be chosen before calling 'super.addNotify()' of the AWT Canvas/Component
since it's being used for it's native creation. The latter gets the AWT GraphicsConfiguration
w/ out overridden 'public GraphicsConfiguration getGraphicsConfiguration()', which itself
utilizes our 'awtConfig' and check for compatibility.

+++

~Sven

On Friday, December 09, 2011 01:30:56 PM gouessej [via jogamp] wrote:
>
> I think he uses something close to this:
> http://www.intel.com/content/www/us/en/chipsets/mainstream-chipsets/mobile-chipset-hm55.html
> http://www.intel.com/content/www/us/en/chipsets/mainstream-chipsets/mobile-chipset-hm55.html 
>
> The woman who asked me to repair the Optiplex GX280 owns a laptop with an
> Intel integrated chip using the same driver on Windows 7, I can ask her to
> help me in about 10 days but we would have a very little time to do it,
> maybe 2 hours in the best case.

ops .. yeah, I guess I am too old to look forward to such a stress :)
But thank you for the offer, Julien.

I guess I will hunt down an Intel sandy bridge desktop/barebone machine these days.

~Sven

On Friday, December 09, 2011 03:11:22 PM Sven Gothel wrote:
> On Friday, December 09, 2011 01:30:56 PM gouessej [via jogamp] wrote:
> >
> > I think he uses something close to this:
> > http://www.intel.com/content/www/us/en/chipsets/mainstream-chipsets/mobile-chipset-hm55.html
> > http://www.intel.com/content/www/us/en/chipsets/mainstream-chipsets/mobile-chipset-hm55.html 
> >
>
> I guess I will hunt down an Intel sandy bridge desktop/barebone machine these days.
>

How about this box:

Lenovo ThinkCentre M71e SFJB5GE
(Windows 7 Professional 64-Bit (OEM))
Lenovo
ThinkCentre M71e SFJB5GE
    Prozessor: Intel® Pentium® Processor G630 (2,7 GHz)
    Grafikchip: Intel® HD Graphics 2000
    Festplatte: 500 GB

Should fit the bill for OpenGL/OpenCL on Intel Sandy Bridge tests ?
The only 'Intel® HD Graphics 3000' machines available were around
200 EUR more expensive and Apple Minis .. well :)

~Sven

JoglAwtCanvas already extends GLCanvas. Why don't I reproduce this bug on my machine? He can't even run a very simple example, even the NEWT version of TUER does not run on his machine.

On Friday, December 09, 2011 03:59:20 PM gouessej [via jogamp] wrote:
>
> JoglAwtCanvas already extends GLCanvas. Why don't I reproduce this bug on my
> machine? He can't even run a very simple example, even the *NEWT* version of
> TUER does not run on his machine.

Ah .. thx a lot for clarification.

So if no 'proven' NativeWindow adapter (AWT/NEWT) works,
but the SharedResourceRunner itself could establish a context (ARB 3.3 here)
one could get the idea that only one context can be created.
Right, that would be very odd - even though, this has been seen on embedded Broadcom
chips a while ago.

Hmm .. interesting.

~Sven

TUER uses a single context, it is "just" a game, it uses a single GLWindow unlike his own program attempting to create several GLCanvas instances. Maybe the problem comes from the creation of the context itself. Is there something common between this problem and what happens in the bug 498?

On Friday, December 09, 2011 07:26:51 PM gouessej [via jogamp] wrote:
>
> TUER uses a single context, it is "just" a game, it uses a single GLWindow
> unlike his own program attempting to create several GLCanvas instances.
> Maybe the problem comes from the creation of the context itself. Is there
> something common between this problem and what happens in the bug 498?
>

JOGL itself creates an internal context itself.

In my previous post where I analyzed the [NV, Ardor3D, ..] bug
I state that even though your AWT component (a GLCanvas itself as you say)
is unable to create even a temp. old non-ARB context (after failing the ARB one)
- _was_ able to properly create that shared ARB context GL 3.3.
Thats is the odd thing, hence I assumed the lack of a proper HDC/PFD-ID initialization.
(Maybe review my previous post w/ your source code .. maybe something indeed was overriden
in a way that it avoids proper initialization, but I don't know.)

Bug 498 is 'only' sporadically visible on this 32bit WinXP system .. hmm.
But your reported system is Win7 64bit .. so I doubt it's the same issue.

I have an old WinXP 32bit machine w/ a pretty old ATI mobility (RV3xx) here,
I will check w/ it later these days .. in case this is not related to the GPU driver at all.

~Sven

This is correct.  Mine has the following:

HM55 Express Chipset LPC Interface Controller - 3B09

This chipset has the Intel graphics integrated.  It's a big laptop.

Gene

If it would be helpful, I can try adding an ssh server to my box, too.  But since the bug results only in an empty OpenGL window, I'm not clear how this would help.  I'm not sure if OpenGL works over Windows Desktop. We could try that.

Gene