jtabbedpane problems (now TileRenderer)

[invictus]

Hi

I am trying to use GLCanvas with jtabbedpane and it doesnt work as expected. When I add a tab with a jpanel containing a glcanvas it doesnt draw the canvas. if I add another one and click on the second tab then the second canvas is shown (however it has a small flicker in the graphics). When I then click the first tab again the first canvas is shown.

I am using yesterdays nightly build of jogl.

I made a small example of the problem on the following address:
http://studweb.hig.no/020843/Scene.java

[Ken Russell]

This appears to be a problem with the JDK. The same thing happens if you add a normal AWT Canvas instead of a JOGL GLCanvas. Also the problem doesn't happen with a recent Mustang weekly build. I would suggest posting on the Swing and AWT forum on javadesktop.org.

[invictus]

The java 6 JDK fixed the issue. Do you know if beta2 is stable enough to keep using instead of version 5?

didnt fix the intel extreme flicker though :p

EDIT:

After a bit of testing using canvas in tabbedpane I have some serious performance issues. I use a shared context for all windows, and the performance is good on the first 5 canvases I created, but every canvas created after that will have lag issues. I have tried having about 10 tabs with canvases sharing context, and the first 5 tabs that is clicked/made visible will have great performance even if I have 10++ tabs, while the rest will lag real bad. Any ideas?

EDIT2:

This seem to be a problem on the intel extreme 2 chip as I just tested it on 2 machines using that card, while on the same crappy SiS card on a machine with less RAM it is going smooth without a problem...this intel extreme graphics 2 issues are really getting on my nerves now as it isnt working and its ruining my project

Games published by our own members! Check 'em out!

[Ken Russell]

This seem to be a problem on the intel extreme 2 chip as I just tested it on 2 machines using that card, while on the same crappy SiS card on a machine with less RAM it is going smooth without a problem...this intel extreme graphics 2 issues are really getting on my nerves now as it isnt working and its ruining my project

Spend the 30 bucks or so to get the lowest-end NVidia card on the market that will go into your PC. I guarantee it will work more reliably than the Intel Extreme chipset. Note: I do not work for NVidia.

You may want to look for more up-to-date Intel video drivers for your hardware.

[invictus]

I have the 7800GT card on my other computer and still have some issues.

The problem for us is that we are using JOGL  for the last project at a bachelor education, and the product is suppose to be used by low-end computers. Since intel extreme graphics seem to be one of the most common graphics cards in use we have problems

Here is a more extensive report of the issues we have had with different hardware so far in the project:
--------------------------------------------------------------------------------------------------------

The computers:

Amd64 x2 3800+
2GB DDR memory
WD raptor 74GB
Geforce 7800GT with newest forceware

Most works. PBuffer code (will post below) work even with destroy unlike most other machines, but with multiple tabs it cant redraw the canvas before its clicked EVERYTIME you do something with the window. Also crashes when using repaint() in reshape method saying something about singlethreadworkaround. Have none of these problems when we are not using tabs.

---

Dell inspiron 510m
CeleronM 1.3ghz
512MB DDR memory
intel extreme graphics 2: tried with both default dell drivers and newest intel drivers

When resizing a window it fill the "new" area with random data. Can be "avoided" if forcing a repaint() at the end of reshape() (although it will have a 1-2 seconds delay before it works) method, but will cause problems for the computer above. Was told it could work if we instead of running repaint() just start a thread that run repaint(), but I cant confirm this. Also have insane lag on each tab created with canvas after 5 tabs are clicked (first 5 tabs still work smooth though). PBuffer code works like a dream though as long as the destroy() on the pbuffer present. If the destroy is removed it will crash if the code is run several times.

-

IBM thinkpad r50e
CeleronM 1.4ghz
512MB DDR memory
intel extreme graphics 2: default ibm drivers

Same as above except that the pbuffer code crash on destroy() method. Someone said it would work if we created a whole new thread just to do destroy(), but I cannot confirm this.

-

Acer TravelMate 2310
Celeron M, 1.2ghz I think
256MB DDR memory (192MB because of shared memory)
SiS m661mx card using newest drivers

Will crash bigtime on pbuffer code, but else everything works like a dream (even though this computer has the worst spesifications).

-

amd athlon xp 1800+
1GB memory
nvidia geforce fx 5900 ultra

Everything seem to work ok with this computer. Both canvases in tabs, pbuffer code, and redraw both with and without repaint() in reshape method.

-

Also barly tried another computer that I do not have the specs of, and the pbuffer code crashed bigtime.

----

PBuffer code:

  protected boolean Capture()
  {
      if(GLDrawableFactory.getFactory().canCreateGLPbuffer())
      {
         GLCapabilities caps = new GLCapabilities();
         caps.setDoubleBuffered(false);
         GLPbuffer offScreenCanvas = GLDrawableFactory.getFactory().createGLPbuffer(caps, null, 1024, 768,

canvas.getContext());
         offScreenCanvas.addGLEventListener(this);
         offScreenCanvas.display();
         offScreenCanvas.removeGLEventListener(this);
         offScreenCanvas.destroy();      //will crash here on half of the computers
         return true;
      } else return false;
  }

reshape code:

   //will display random trash on new area until a repaint is forced on half of the computers. on one computer a forced repaint will

crash the application saying something about singlethread. Even if a repaint is forced it will take a second or two for the random trash

disapears and the image is streched.

  public void reshape(GLAutoDrawable glDrawable, int x, int y, int width, int height)
  {
    GL gl = glDrawable.getGL();
    int width_l = width;
    int height_l = height;
    if(height <= 0)
      height = 1;
    final float h = (float)width_l /(float)height_l;
    ratio = h;
      gl.glViewport(0, 0, width, height);
      gl.glMatrixMode(GL.GL_PROJECTION);
      gl.glLoadIdentity();
    glu.gluPerspective(45.0f, h, 0.1f, 200.0);
      gl.glMatrixMode(GL.GL_MODELVIEW);
    canvas.repaint();               //this is causing problems for some machines, but for some not
  }

tabs:

   Not much to say about the tabs. We have a static Context used for keeping track on the context so every canvas get the same

context on "new GLCanvas".

from the panel holding the canvas:

  public static GLContext context = null;


from the contructor of the panel holding the canvas:

    if(context != null)
      canvas = new GLCanvas(caps, null, context, null);
    else
    {
      canvas = new GLCanvas(caps);
      context = canvas.getContext();
    }


The panel holding this data is used with this code:

   tabbedpane.addTab("name", new Scene()); where Scene inherits JPanel and place the canvas as BorderLayout.CENTER

--

The resize/redraw issues are described in the following threads:
http://www.java-gaming.org/forums/index.php?topic=12225.0
http://www.java-gaming.org/forums/index.php?topic=8738.0

The tab issues are described in the following thread:
http://www.java-gaming.org/forums/index.php?topic=12761.0

I hope the fault is ours so its fixable...otherwise we have a hudge problem

[Ken Russell]

Thanks for posting this information and sorry about the problems you're running into. Unfortunately even with these descriptions it's impossible to guess what could be going on in most cases. Can you provide output and crash logs for the various crashes you're reporting? What output indicates something about the single-threaded workaround?

Do you have a small test case reproducing some of these problems?

Can you do any workarounds like using a GLJPanel or doing the tabbed portion of your GUI using OpenGL rather than the AWT so that you have only one GLCanvas?

[invictus]

Thanks for posting this information and sorry about the problems you're running into. Unfortunately even with these descriptions it's impossible to guess what could be going on in most cases. Can you provide output and crash logs for the various crashes you're reporting? What output indicates something about the single-threaded workaround?

About the tabbing lags I dont have any logs, but I think I will go for another tabbing solution using only one canvas instead so it doesnt really matter anymore.

I will supply you with a log from the pbuffer crash with a working example when I get a hold of the rest of my programming group.

When it comes to the resize issues with intel extreme graphics I dont know more than I (and another guy in that other thread I linked to) already told you since there is no crash, but just a visible bug.

Most of the issues were related to the tabbing and usage of multiple canvases anyway it seems.

But I ask anyway: when forcing a redraw using canvas.repaint() or canvas.display() (dont know wich is better), should it be necessary to put it in a own thread? We have had to do this a couple of places to avoid crashes when forcing redraw (often after an input event that is changing the scene). That is the singlethread-thingy exception I was talking about. I will try to get a groupmember to reproduce this error so you can see for your self.

Do you have a small test case reproducing some of these problems?

I can try making something, but that wont be until beginning of next week

Can you do any workarounds like using a GLJPanel or doing the tabbed portion of your GUI using OpenGL rather than the AWT so that you have only one GLCanvas?

I will create a custom tabbedpane that only use one single canvas instead of multiple. I figured out that this would be better for me anyway.


And last but not least; thank you so much for the support and help here on the forums. It helps against the frustration to get help from someone that know JOGL better

[Ken Russell]

But I ask anyway: when forcing a redraw using canvas.repaint() or canvas.display() (dont know wich is better), should it be necessary to put it in a own thread? We have had to do this a couple of places to avoid crashes when forcing redraw (often after an input event that is changing the scene). That is the singlethread-thingy exception I was talking about. I will try to get a groupmember to reproduce this error so you can see for your self.

There should be no difference. JOGL moves all of the OpenGL work onto a single thread internally anyway. I assume you aren't calling Threading.disableSingleThreading() or specifying the opengl.1thread system property on the command line.

I did notice recently that there are a couple of OpenGL-related calls that still get made on the current thread instead of the "OpenGL worker thread" and if the drivers are suspect then those could be causing problems. I've made a note to look into these issues.

I can try making something, but that wont be until beginning of next week

No rush.

And last but not least; thank you so much for the support and help here on the forums.

You're welcome and sorry for the trouble. We want to make this library as robust as possible.

[invictus]

Ok here is the PBuffer example:

http://home.online.no/~bj-bakke/hello.java

When running the application press F2 when destroy() isnt commented out in the Capture method.
If the destroy() is commented you need to press F2 as fast as possible 2-5 times.


The results:

dell laptop with intel extreme graphics WITH destroy()
works fine

dell laptop with intel extreme graphics WITHOUT destroy()
crash with the following exception:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: javax.med
ia.opengl.GLException: pbuffer creation error: wglCreatePbufferARB() failed: tri
ed 1 pixel formats, last error was: (Unknown error code 0)
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:268)

        at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.maybeDoSingleThr
eadedWorkaround(WindowsGLDrawableFactory.java:213)
        at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.createGLPbuffer(
WindowsGLDrawableFactory.java:160)
        at hello.Capture(hello.java:139)
        at hello.keyPressed(hello.java:161)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)

        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)


Acer laptop with SiS card WITH destroy()
the following exception:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: javax.med
ia.opengl.GLException: Error releasing pbuffer device context: error code 0
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:268)

        at com.sun.opengl.impl.GLPbufferImpl.destroy(GLPbufferImpl.java:177)
        at hello.Capture(hello.java:143)
        at hello.keyPressed(hello.java:161)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)

        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: javax.media.opengl.GLException: Error releasing pbuffer device contex
t: error code 0
        at com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.destroy(WindowsP
bufferGLDrawable.java:92)
        at com.sun.opengl.impl.GLPbufferImpl$DestroyAction.run(GLPbufferImpl.jav
a:253)
        at com.sun.opengl.impl.GLWorkerThread$WorkerRunnable.run(GLWorkerThread.
java:241)
        at java.lang.Thread.run(Unknown Source)

Acer without destroy()


#
# An unexpected error has been detected by Java Runtime Environment:
#                        +----------------------------+
#  EXCEPTION_ACCESS_VIOLA¦Enter char to copy up to:   ¦e90c, pid=3724, tid=3272
#                        +----------------------------+
# Java VM: Java HotSpot(TM) Client VM (1.6.0-beta-b59g mixed mode, sharing)
# Problematic frame:
# C  [sisgl.dll+0x7e90c]
#
# An error report file with more information is saved as hs_err_pid3724.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

The log is located here:

http://home.online.no/~bj-bakke/hs_err_pid3724.log


The IBM laptop with intel extreme graphics have the same crash as the acer laptop WITH destroy(). without destroy() I dont know.

[invictus]

I am sorry to do this, but I need to bump the last reply in this thread regarding the pbuffer issues. Any new ideas on this problem with pbuffer and destroy?

Games published by our own members! Check 'em out!

[Ken Russell]

Sorry to say this but you're running into problems with crappy OpenGL drivers. You should file bugs with Intel and SiS. I don't think JOGL is doing anything wrong here. Your test case works fine on my laptop with an NVidia chipset.

Regardless I don't think you should be creating and destroying a pbuffer every time you want to take a screenshot. Even NVidia's drivers don't deal well with rapid creation and destruction of off-screen surfaces like Frame Buffer Objects. You should lazily create the pbuffer the first time the user requests a screenshot and hold on to it for subsequent screenshots, resizing it if necessary. Please try this and see whether it helps.

[invictus]

Ok. So its not needed to do destroy() at all then?

[Ken Russell]

Right, just hold on to the pbuffer and reuse it over and over again.

[invictus]

Ok I now works on more machines than before.

What I did was to remove the .destroy(), replace the offscreencanvas.display() with .repaint(), and finally made sure the pbuffer only got init once.

It works on all except one of the two intel extreme graphics 2 machines. Get the message "Could not find suitable pixelformat..." even tho I am using the lowest possible pixelformat setting: default with doublebuffering off. If I could just find out where to trap that exception I could probably fix it by dumping the framebuffer and scale it as a backup solution. Seem like the exception happens in a event-thread I dont have access to because now I have tried catching GLException both in the triggering code and in init & display. Any idea how I can catch the suitable pixel format exception?

[Ken Russell]

First, GLPbuffer.repaint() just calls GLPbuffer.display(), so there should be no difference in behavior between them.

If GLPbuffer.display() causes an exception to be thrown on the AWT event dispatch thread, this exception should be propagated back to your thread as a GLException and you should be able to catch it there. If this doesn't seem to be working, could you please post some code?

[invictus]

The code sample I am working against is at this address:
http://home.online.no/~bj-bakke/hello.java

When run you push F2 to take the screenshot (and get the crash). I suppose it wont crash on your machine, but if you uncomment line 210 you get the same exception as we get on the one computer. The exception is caught in the Capture() method, but it still give us a stacktrace a second later for some reason. What I want is to get rid of that stacktrace.

Line 210 is ONLY for reproducing the exception on other machines that dont get it otherwise!

Btw you were right about repaint() and display() it seem.

You can see I already implemented the backup solution with gluScaleImage (although the images are 3 times as big and 3 times as ugly using that compared to the pbuffer ones). In the Capture() method it just tell the pbuffer to display and save to file if possible or else it should just repaint the canvas, dump the canvas framebuffer, scale it up, and save it to file.

[invictus]

It seem like the exception that create this stacktrace is produced every time display() is run after pbuffer fail and I try using the backup solution. I have no idea how to fix this as that spesific exception cant be caught in neither display() or Capture().

[Ken Russell]

Is this the second exception you were getting?

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22

Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Should not reach here         at javax.media.opengl.glu.GLU.gluScaleImageJava(GLU.java:1486)         at javax.media.opengl.glu.GLU.gluScaleImage(GLU.java:1608)         at hello.display(hello.java:140)         at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)         at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:281)         at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)         at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:258)         at javax.media.opengl.GLCanvas.display(GLCanvas.java:130)         at javax.media.opengl.GLCanvas.paint(GLCanvas.java:142)         at javax.media.opengl.GLCanvas.update(GLCanvas.java:213)         at sun.awt.RepaintArea.updateComponent(RepaintArea.java:239)         at sun.awt.RepaintArea.paint(RepaintArea.java:216)         at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:254)         at java.awt.Component.dispatchEventImpl(Component.java:4031)         at java.awt.Component.dispatchEvent(Component.java:3803)         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

If so, this was a bug in the Java gluScaleImage implementation; sorry about that. The fix will be present in the nightly builds dated 4/28 or later.

You should also look into the com.sun.opengl.util.TileRenderer class and demos.misc.TiledRendering demo for producing higher-resolution screen shots.

[invictus]

Ok I will try TileRenderer instead. Any idea on where to get started?

[Ken Russell]

As mentioned above, look at the source code for the demos.misc.TiledRendering demo in the jogl-demos workspace.

[invictus]

oh...I just noticed that code also was using pbuffers. I was hoping to not using pbuffer since some of the project machines keep getting these pixel format exceptions when using pbuffers. What I need is a 800x600 screenshot of a variable size canvas...

[Ken Russell]

You don't need to use a pbuffer with the TileRenderer. It can read its results from the back buffer so they don't need to be displayed on-screen. Try changing the test case to use an on-screen GLCanvas.

[invictus]

Really? I did not know that. Any idea how to use/save the backbuffer without displaying it then? Or am I way off here...

I think this might be the solution I have been looking for for a couple of months now if I can just get it working

[Ken Russell]

Look at the man pages for glReadBuffer and glReadPixels.

[invictus]

Hmm...is there any standard "this is what your doing wrong" if I get the following output using TileRenderer?



Its suppose to render _one_ large triangle.

The code is as usual over at http://home.online.no/~bj-bakke/hello.java

If I can just get this one working I am as good as done with my project

UPDATE: It works if I run my app in fullscreen. That means if the tilesize is bigger than the image size. If not then I get this weird image.

[Ken Russell]

You definitely need to call trPerspective in order to tell the library what the overall view frustum is that you're rendering into. You should also make sure that your rendering routine "disp" produces exactly the same results no matter when you call it in the beginTile / endTile loop. I think you are also not supposed to modify the projection matrix in your rendering routine. You may also want to simply set a boolean flag when the capture key is pressed and do the capturing work in your display() routine instead of doing manual context manipulation. Beyond that I would recommend you just study the TiledRendering demo.

[invictus]

You definitely need to call trPerspective in order to tell the library what the overall view frustum is that you're rendering into.

I tried that without any different results. Perhaps I am doing it wrong.

You should also make sure that your rendering routine "disp" produces exactly the same results no matter when you call it in the beginTile / endTile loop.

Do you mean the rot += thingy? That is way gone but it didnt matter for the result. was mostly for the animator.

I think you are also not supposed to modify the projection matrix in your rendering routine.

Where do I do that? Perhaps I dont get what you mean...

Beyond that I would recommend you just study the TiledRendering demo.

I did...I even tried swapping the drawGears function with my triangle, but then I got the same result. I really dont get what going on.

[invictus]

I managed to get the TiledRendering demo to work with my triangle just as I wanted it so I guess I perhaps will get it working on the canvas also soon. Thanks for the help so far