TextRenderer + VertexBufferObject + GLX on unix

Hi!

I have some jogamp app., rendering some text - TextRenderer object with default settings.
App. runs fine on my machine.
( OpenSUSE 11.3 64bit, nVIDIA 9400GT, glxinfo says that direct rendering is enabled, and OpenGL 3.3.0 is available, plus both GLX client and server version is 1.4 )

I've tried exporting display to another machine ( export DISPLAY=192.168.xxx.xxx:0.0 )
glxinfo then says that GLX client and server are the same as on my machine ( 1.4 ), OpenGL is 2.1.2 - card is nVIDIA 8400GS - of course direct rendering is disabled, because I've exported my display to another machine and X Server's GLX cannot be bypassed... GL commands are turned into byte stream, pushed over network, than de-serialized and finally rendered with the remote graphics card to the remote display - if I understand X Server correctly.

GLX 1.4 means OpenGL 1.4, and TextRenderer is trying to create vertex buffer object, and he fails, because that's a 1.5+ feature.

My question is:
Why is this method returning TRUE in my situation? : TextRenderer#is15Available(GL gl).

Note: gl.isExtensionAvailable("GL_ARB_vertex_buffer_object") returns FALSE when is15Available returns TRUE.

Shouldn't TextRenderer check only for the needed feature instead of whole GL version?

Actually, even some graphics cards with only OpenGL 1.3 support VBO.

gl.isExtensionAvailable("GL_VERSION_1_5") returns true on your machine so is15Available returns true too. As far as I know, we do not test if ARB_vertex_buffer_object is available in TextRenderer. We use VBOs if OpenGL 1.5 is available and if the flag about vertex arrays is set to true. Maybe set this flag to false to work around this bug. It is strange, if the creation of a VBO fails, we fall back on the immediate mode. Can you post a stack trace please?

Hi!

I've bypassed the problem by manually checking for VBO's, but this behaviour is strange. It reports GL 1.5 is available but VBO's not, which shouldn't be possible - anyway the newest GLX is for GL 1.4, so i think isGL1.5 is looking at different GL context than the application uses ( application must use GLX server context on the other machine, because I've exported the display )

Here is the stack trace:

> export DISPLAY=192.168.100.108:0.0 ( other machine, 32bit ubuntu )
> xlogo ( works fine )
> glxgears ( works fine )
> java -jar -Djava.library.path=/home/barcsik/Workspace/NetBeans/3D\ Surface/lib/natives-linux-amd64 3*
Info: XInitThreads() called for concurrent Thread support
libEGL warning: No supported client API
   ... ( many times )...
libEGL warning: No supported client API
Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: array vertex_buffer_object must be enabled to call this method
        at jogamp.opengl.gl4.GL4bcImpl.checkBufferObject(GL4bcImpl.java:32235)
        at jogamp.opengl.gl4.GL4bcImpl.checkArrayVBOEnabled(GL4bcImpl.java:32262)
        at jogamp.opengl.gl4.GL4bcImpl.glVertexPointer(GL4bcImpl.java:31131)
        at com.jogamp.opengl.util.awt.TextRenderer$Pipelined_QuadRenderer.drawVertexArrays(TextRenderer.java:1815)
        at com.jogamp.opengl.util.awt.TextRenderer$Pipelined_QuadRenderer.draw(TextRenderer.java:1791)
        at com.jogamp.opengl.util.awt.TextRenderer$Pipelined_QuadRenderer.access$000(TextRenderer.java:1733)
        at com.jogamp.opengl.util.awt.TextRenderer.flushGlyphPipeline(TextRenderer.java:813)
        at com.jogamp.opengl.util.awt.TextRenderer.endRendering(TextRenderer.java:709)
        at com.jogamp.opengl.util.awt.TextRenderer.end3DRendering(TextRenderer.java:555)
        at SpecUI.UICurveX.Surface3D.GLFont.end3DRendering(GLFont.java:424)
        at SpecUI.UICurveX.Surface3D.Surface3D$Labels.render(Surface3D.java:4470)
        at SpecUI.UICurveX.Surface3D.Surface3D.display(Surface3D.java:740)
        at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:191)
        at javax.media.opengl.awt.GLJPanel$Updater.display(GLJPanel.java:682)
        at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:191)
        at jogamp.opengl.GLPbufferImpl$DisplayAction.run(GLPbufferImpl.java:288)
        at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:363)
        at jogamp.opengl.GLPbufferImpl.invokeGL(GLPbufferImpl.java:274)
        at jogamp.opengl.GLPbufferImpl.display(GLPbufferImpl.java:147)
        at javax.media.opengl.awt.GLJPanel$PbufferBackend.doPaintComponentImpl(GLJPanel.java:1227)
        at javax.media.opengl.awt.GLJPanel$AbstractReadbackBackend.doPaintComponent(GLJPanel.java:996)
        at javax.media.opengl.awt.GLJPanel.paintComponent(GLJPanel.java:384)
        at SpecUI.UICurveX.Surface3D.GLCompositeJPanel.paintComponent(GLCompositeJPanel.java:87)
        at javax.swing.JComponent.paint(JComponent.java:1029)
        at javax.swing.JComponent.paintChildren(JComponent.java:862)
        at javax.swing.JComponent.paint(JComponent.java:1038)
        at javax.swing.JComponent.paintChildren(JComponent.java:862)
        at javax.swing.JComponent.paint(JComponent.java:1038)
        at javax.swing.JLayeredPane.paint(JLayeredPane.java:567)
        at javax.swing.JComponent.paintChildren(JComponent.java:862)
        at javax.swing.JComponent.paintToOffscreen(JComponent.java:5131)
        at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:278)
        at javax.swing.RepaintManager.paint(RepaintManager.java:1224)
        at javax.swing.JComponent.paint(JComponent.java:1015)
        at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:21)
        at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60)
        at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:97)
        at java.awt.Container.paint(Container.java:1780)
        at java.awt.Window.paint(Window.java:3375)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:796)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:713)
        at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:693)
        at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:125)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Do you mix vertex arrays and VBO in your application?

I have only basic stuff. GL_LINES and GL_QUADS with the most basic commands - a bunch of vertice/color pairs. No vertex arrays.

Something seems to disable VBO before the call to TextRenderer.end3DRendering. Do you use glPushAttrib or glPushClientAttrib? Do you reproduce this bug with a rudimentary example like the one that I put on Wikipedia?

No, I haven't used any *Attrib. I draw only some basic lines and triangles, nothing more.

I'll try to reproduce this with the dumbest possible scenario, as soon as possible. ( today/tomorrow )

I've tried with the example from wikipedia, I've just added a textrenderer with useVertexArrays = true, then  begin3D-draw3D-end3D. I've made a version with GLCanvas and another one with GLJPanel, and then re-run the scenario:

export DISPLAY=another_machine_ip:0.0
java -jar -Djava.library.path=...  Test.jar

and got the sam expection I've posted before ( for both versions ).

Note:
when i've killed the GLJpanel version with Ctrl^C it dropped SIGSEGV, but I think it's another problem and it's not related to TextRenderer, just to GLJPanel:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fa52c0111bb, pid=9111, tid=140347287684880
#
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libxcb.so.1+0xa1bb]  xcb_writev+0x1b
#
# An error report file with more information is saved as:
# /home/barcsik/Workspace/DefaultGLJPanel JOGL 2.0/dist/hs_err_pid9111.log
#
# If you would like to submit a bug report, please visit:hs_err_pid9111.log
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted

PS.: I've uploaded the log file too.

It is strange, it crashes on makeCurrent() :s

Attila Barcsik wrote

when i've killed the GLJpanel version with Ctrl^C it dropped SIGSEGV, but I think it's another problem and it's not related to TextRenderer, just to GLJPanel:

Maybe this is due to the Animator trying to draw to the GL context after the context has been disposed as a result of ctrl-c? The ctrl-c may not be shutting down the animator thread properly.

Wade Walker wrote

Maybe this is due to the Animator trying to draw to the GL context after the context has been disposed as a result of ctrl-c? The ctrl-c may not be shutting down the animator thread properly.

I use passive rendering, I call the repaint() manually when needed.
( but I have an Animator in case I want to see correct FPS, but it wasn't running )

The AWTAnimatorImpl is in your log file stack dump -- am I reading this wrong?  It looks like it causes a dirty region repaint that eventually hits GL:

j  jogamp.opengl.x11.glx.GLX.dispatch_glXMakeContextCurrent1(JJJJJ)Z+0
j  jogamp.opengl.x11.glx.GLX.glXMakeContextCurrent(JJJJ)Z+33
j  jogamp.opengl.x11.glx.X11GLXContext.glXMakeContextCurrent(JJJJ)Z+16
j  jogamp.opengl.x11.glx.X11GLXContext.makeCurrentImpl(Z)V+49
j  jogamp.opengl.GLContextImpl.makeCurrentLocking()I+259
j  jogamp.opengl.GLContextImpl.makeCurrent()I+106
j  jogamp.opengl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+147
j  jogamp.opengl.GLPbufferImpl.invokeGL(Ljava/lang/Runnable;)V+17
j  jogamp.opengl.GLPbufferImpl.display()V+5
j  javax.media.opengl.awt.GLJPanel$PbufferBackend.doPaintComponentImpl()V+4
j  javax.media.opengl.awt.GLJPanel$AbstractReadbackBackend.doPaintComponent(Ljava/awt/Graphics;)V+1
j  javax.media.opengl.awt.GLJPanel.paintComponent(Ljava/awt/Graphics;)V+174
j  SpecUI.OpenGL.GLCompositeJPanel.paintComponent(Ljava/awt/Graphics;)V+7
j  javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+290
j  javax.swing.JComponent.paintToOffscreen(Ljava/awt/Graphics;IIIIII)V+41
j  javax.swing.BufferStrategyPaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)Z+157
j  javax.swing.RepaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)V+52
j  javax.swing.JComponent._paintImmediately(IIII)V+679
j  javax.swing.JComponent.paintImmediately(IIII)V+83
j  javax.swing.RepaintManager.paintDirtyRegions(Ljava/util/Map;)V+193
j  javax.swing.RepaintManager.paintDirtyRegions()V+46
j  com.jogamp.opengl.util.AWTAnimatorImpl$1.run()V+374
j  java.awt.event.InvocationEvent.dispatch()V+11
j  java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+26
j  java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+204
j  java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j  java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j  java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j  java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j  java.awt.EventDispatchThread.run()V+9
v  ~StubRoutines::call_stub

Wade Walker wrote

The AWTAnimatorImpl is in your log file stack dump -- am I reading this wrong?  It looks like it causes a dirty region repaint that eventually hits GL:

Uff, sorry! I've messed it up. In the main application, which caused this whole GLX/TextRenderer related problem i don't use an Animator, but this second rudimentary example I've tried uses it! And yes I killed the app. with Ctrl-C, and now it makes sense. The AWT thread tries to repaint, but i've already pressed Ctrl-C and it killed some other parts of the application, and it tries to repaint with OpenGL which is already destroyed.

Unfortunately I've had bad experiences with GLJPanel from the older versions of jogl ( pre-RC1 ), and that's why I thought it's a GLJPanel problem again, but this core dump is clearly not a bug.