JSR-231 1.1.1a Released

[Ken Russell]

Okay, I will change my code when I use JOGL 1.1.0. Does JOGL really take into account glPrioritizeTexture ?

JOGL just passes these calls along to OpenGL, so it depends on whether your OpenGL implementation respects it.

[ildella]

Please post here with any questions or comments about the new build.

Hi. I always receive this error

 javax.media.opengl.GLException: Error making context current
   at com.sun.opengl.impl.x11.X11GLContext.makeCurrentImpl(X11GLContext.java:141)
   at com.sun.opengl.impl.x11.X11OffscreenGLContext.makeCurrentImpl(X11OffscreenGLContext.java:74)
   at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
   at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
   at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:661)
   at org.progx.jogl.CompositeGLPanel.paintComponent(CompositeGLPanel.java:44)
   at javax.swing.JComponent.paint(JComponent.java:1022)

With 1.1.0 and with 1.1.1RC3.

A similar issue is described here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6503420
and closed as "not a bug" due to the fact that is related to some old driver.
But my hardware is a macbook core2duo with a intel video card and the OS is Ubuntu Feisty Fawn.

Any hint?

[Ken Russell]

But my hardware is a macbook core2duo with a intel video card and the OS is Ubuntu Feisty Fawn.

This isn't exactly a mainstream OS and hardware combination. I think the problem is buggy pbuffer support in the open-source Intel video drivers. I'm not sure which version of the drivers you're running but you might want to see if you can find a more recent version or report the problem to Intel.

Games published by our own members! Go get 'em!

[ildella]

This isn't exactly a mainstream OS and hardware combination. I think the problem is buggy pbuffer support in the open-source Intel video drivers. I'm not sure which version of the drivers you're running but you might want to see if you can find a more recent version or report the problem to Intel.

maybe.
But maybe that problems comes from jogl:
http://forum.worldwindcentral.com/archive/index.php?t-9627.html
tag says: "There are still several issues with using JOGL in a JPanel cross-platform. We're working with Sun on them."

Maybe this is a matter of driver, of course.

Actually, this are some info at runtime:
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
GL_VENDOR: Tungsten Graphics, Inc
GL_RENDERER: Mesa DRI Intel(R) 945GM 20061017 x86/MMX/SSE2
GL_VERSION: 1.3 Mesa 6.5.2

[Ken Russell]

maybe.
But maybe that problems comes from jogl:
http://forum.worldwindcentral.com/archive/index.php?t-9627.html
tag says: "There are still several issues with using JOGL in a JPanel cross-platform. We're working with Sun on them."

I work closely with the World Wind development team and am aware of the portability issues with the GLJPanel. Especially in this case I am pretty sure the problem is in the video driver and not in JOGL.

Maybe this is a matter of driver, of course.

Actually, this are some info at runtime:
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
GL_VENDOR: Tungsten Graphics, Inc
GL_RENDERER: Mesa DRI Intel(R) 945GM 20061017 x86/MMX/SSE2
GL_VERSION: 1.3 Mesa 6.5.2

Unfortunately it doesn't look like your graphics chip is supported with Intel's most recent open-source driver release, so I think you may be out of luck. Since you're running on a MacBook, why not run Mac OS X? The video driver and OpenGL support will almost certainly be better than on Linux.

[COrthbandt]

I have two requests regarding JNLPAppletLauncher:

1st: I'm trying to get status information out of JNLPAppletLauncher from JavaScript.
As soon as my sub applet runs, I can do this through getSubApplet().
But I'd like to have a way to get the current progress bar text from the launcher and
ideally the progress percentage as well.
The motivation for this is to create the applet more or less hidden (1x1 pixel) and
resize it as soon as my sub applet reports to have completed loading.
This way I can display interactive DHTML/JS content while the applet is loading.
But for error messages and such it would still be useful to display the progress bar
text somewhere in my loading screen.

2nd: JNLPAppletLauncher automatically fetches all referenced extensions. I could
use a flag to specify delayed loading of these. Such that my sub-applet triggers the
loading of add-on libraries. Rationale for this: Display a customized loading screen,
not just an image.

As you probably guess both requests target the same problem: Making the load time
a nice experience for the user by displaying other content.

[DzzD]

I think this thread may interest you and about progress download, it is also related to JOGL release

http://www.java-gaming.org/forums/index.php?topic=16911.0

Bruno

[Ken Russell]

I have two requests regarding JNLPAppletLauncher:

1st: I'm trying to get status information out of JNLPAppletLauncher from JavaScript.
As soon as my sub applet runs, I can do this through getSubApplet().
But I'd like to have a way to get the current progress bar text from the launcher and
ideally the progress percentage as well.
The motivation for this is to create the applet more or less hidden (1x1 pixel) and
resize it as soon as my sub applet reports to have completed loading.
This way I can display interactive DHTML/JS content while the applet is loading.
But for error messages and such it would still be useful to display the progress bar
text somewhere in my loading screen.

I agree this is a problem, but there is little chance we will be able to support this in the JNLPAppletLauncher directly. My understanding is that doing so is complicated and may involve the creation of subordinate class loaders, which complicates things significantly in the context of applets. We are working on a new implementation of the Java Plug-In in which we will aim to address this problem more generally. In the meantime you may want to try a Google search for "applet lazy loading progress bar" and see if any of the hits are applicable.

2nd: JNLPAppletLauncher automatically fetches all referenced extensions. I could
use a flag to specify delayed loading of these. Such that my sub-applet triggers the
loading of add-on libraries. Rationale for this: Display a customized loading screen,
not just an image.

As you probably guess both requests target the same problem: Making the load time
a nice experience for the user by displaying other content.

This is probably achievable, and you should file an RFE with the Issue Tracker on the JNLPAppletLauncher home page. However my own experience is that the native libraries for most of these extensions are typically fairly small, and don't take that long to download anyway. Do you have differing experience?

[emzic]

just curious: about when is the RC going to be final? it's been 5 months since the last release and i'd really like to use the new features and bugfixes.

[Ken Russell]

I apologize for the long delay. There are a couple of pieces of stellar work that have been contributed recently: a new glyph-based (and still Unicode-correct) TextRenderer by John Burkey and a Java port of most of the GLU NURBS functionality by Tomas Hrasky. I want to integrate these and do one more RC build for everyone to try before making 1.1.1 final. However, I have had no time to integrate these changes for the past couple of weekends -- all of my available time is going into the day job on the Java Plug-In. I anticipate the crunch will be over soon. Thanks for your continued patience.

Games published by our own members! Go get 'em!

[emzic]

thanks for the update! i'm looking forward to the new textrenderer and also the java-plugin (is it the consumer-jre aka java-kernel) ?

[Ken Russell]

"Project Hamburg", formerly known as the Consumer JRE, has several sub-projects. Java Kernel is another, but different, sub-project, which aims to reduce the initial download size. I was just informed yesterday that the new Java Plug-In is being integrated into Project Hamburg, so soon we will have a much more robust platform for deployment of 3D applets.

[kappa]

Sounds really interesting, when you say Java Plug-In, do you mean applet plugin or jws?

Can't wait to see how this turns out, got any more info on whats changed or what features this new plugin will have ?

[emzic]

a new glyph-based (and still Unicode-correct) TextRenderer by John Burkey

can you let us know, when this new textrenderer is checked in? i want to give it a try as soon as possible. thanks!

[turquoise3232]

can you let us know, when this new textrenderer is checked in? i want to give it a try as soon as possible. thanks!

I must tell "+1" on this beacause i tried a lot of different strings (objects id by example) and when the number reaches around 200/300 the performances drops a lot.
I understand that the cache is full and time is spend swaping and clearing it...
But with the glyph-based TextRenderer... well my hopes are great, and since someone clever than me did it I don't want to start diving into a buggy implementation on my own!

So Ken I wish you good luck for the Java Plug-in, and I hope you can save a little time to the glyphs.

[Ken Russell]

JSR-231 1.1.1 release candidate 4 has been released on October 9, 2007. This release contains two substantial contributions from members of the community.

John Burkey, formerly of Apple Computer, has rewritten the TextRenderer utility class to use glyph-by-glyph caching in most cases, falling back to the previous String-by-String caching mechanism only where Unicode support demands it. John's new implementation provides huge speedups for applications rendering medium to large amounts of dynamic text. He also single-handedly solved all of the outstanding bugs in the TextRenderer. I'm personally very grateful for this contribution.

Tomas Hrasky, a student at the University of Hradec Králové in the Czech Republic, has ported the core of the GLU NURBS code from C++ to Java. This provides rendering of curved lines and surfaces via the traditional GLU APIs. There are example applications under demos.nurbs in the jogl-demos source tree (not yet available via Java Web Start). This is a substantial contribution and has been done very elegantly. I'd like to publicly thank Tomas for doing this work and contributing it to the JOGL project. There is still unimplemented functionality, such as trimmed surfaces and NURBS callbacks; please see the README.txt in src/classes/com/sun/opengl/impl/nurbs/ in the JOGL source tree and consider contributing code to move it toward completion.

The main JOGL JNLP extension file on download.java.net has been updated to point at the RC4 release, and there is also a stable JNLP file for the RC4 release. See the JOGL User's Guide for details.

The current plan is to do another maintenance review of JSR-231 1.1.1 to add the NURBS-related entry points to the public JSR-231 API. This should take roughly a month before we can then call version 1.1.1 final. In the meantime, please try this new build and post with any problems or questions.

[emzic]

thank you very much for this!

does jogl provide a default implementation for the textrenderer's RenderDelegate?
or in other words, how would one implement the new functions
public void drawGlyphVector(Graphics2D graphics, GlyphVector gv, int x, int y)
public Rectangle2D getBounds(CharSequence arg0, Font arg1, FontRenderContext arg2)

edit: i am currently giving this a try:

1   2   3   4   5   6   7   8

public void drawGlyphVector(Graphics2D graphics, GlyphVector gv, int x, int y) {          graphics.drawGlyphVector(gv, x, y);       }       public Rectangle2D getBounds(CharSequence cs, Font font, FontRenderContext frc) {          GlyphVector gv = font.createGlyphVector(frc, cs.toString());          return gv.getPixelBounds(frc, 0, 0);       }

i am experiencing some artifacts where certain characters are cut off at the end. it looks like if the pixels in the last column are not shown. chances are high that the bug is in my code... i will need to investigate this further before i report a bug.

thanks!

[Ken Russell]

See the CustomText demo in the jogl-demos workspace for an example of how to use the RenderDelegate mechanism.

Note: we have discovered a problem with the 1.1.1-rc4 release causing breakage of NASA's World Wind Java. For the time being we've reverted the extension JNLP back to the 1.1.1-rc3 release and will likely push a 1.1.1-rc5 after tracking down the cause of the breakage.

[turquoise3232]

Hi, I've tested the new glyph based cache for text rendering and noticed a 10 fold gain in speed on my 1000 strings display for object identification!

So many thanks to John Burkey for his glyph by glyph implementation and to Ken for it's always fast and good contribution to jogl growth !

[Ken Russell]

JSR-231 1.1.1 release candidate 5 has been released on October 11, 2007. This release fixes a couple of bugs in RC4 which broke NASA's World Wind Java in particular. If you downloaded RC4, please download this release. Please post with any problems, questions or comments.

[emzic]

here is a screenshot of the artifact i was talking about:

[Ken Russell]

Can you please provide a small self-contained test case?

[emzic]

ok, here is a testcase, that produces the artifacts with RC5:

it seems though, as this only happens with a certain font
new java.awt.Font("Verdana", java.awt.Font.PLAIN, 10);

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71   72   73   74   75   76   77   78   79   80   81   82   83   84   85   86   87   88   89   90   91   92   93   94   95   96   97   98   99   100   101   102

import java.awt.Frame; import java.awt.event.KeyEvent; import java.awt.event.KeyListener; import java.awt.event.MouseEvent; import java.awt.event.MouseListener; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import javax.media.opengl.GL; import javax.media.opengl.GLAutoDrawable; import javax.media.opengl.GLCanvas; import javax.media.opengl.GLEventListener; import javax.media.opengl.glu.GLU; import com.sun.opengl.util.Animator; import com.sun.opengl.util.j2d.TextRenderer; public class TextTest extends Frame implements GLEventListener {    private static final long serialVersionUID = 1L;        int width, height;    public static void main(String[] args) {       new TextTest();          }        GLCanvas canvas;    TextRenderer tr ;    String whitespacestring = "emzic";//"h e l l o w o r l d . t h i s i s a s t r i n g w i t h l o t s o f s p a c e s";   Animator animator;        public TextTest() {       super("TextTest");       this.setSize(800, 200);       canvas = new GLCanvas();       canvas.addGLEventListener(this);       add(canvas);                   animator = new Animator(canvas);       animator.setRunAsFastAsPossible(false);       animator.setPrintExceptions(true);       animator.start();                   setVisible(true);       addWindowListener(new WindowAdapter() {          public void windowClosing(WindowEvent e) {             System.exit(0);          }       });    }    public void display(GLAutoDrawable drawable) {       GL gl = drawable.getGL();       gl.glClearColor(1,1,1,1);       gl.glClear(GL.GL_COLOR_BUFFER_BIT|GL.GL_DEPTH_BUFFER_BIT);                     gl.glMatrixMode(GL.GL_PROJECTION);       gl.glLoadIdentity();             new GLU().gluPerspective(45f, (float)width/(float)height, 0.1f, 1000f);             gl.glMatrixMode(GL.GL_MODELVIEW);       gl.glLoadIdentity();             gl.glTranslatef(-10,-3,-10);             gl.glRotatef(1,0,0,1);             gl.glScalef(0.1f,0.1f,0.1f);             tr.begin3DRendering();       tr.draw("some text", 0, 0);       tr.draw("bla blo blu", 0, 14);       tr.draw(whitespacestring, 0, 28);       tr.end3DRendering();          }    public void init(GLAutoDrawable arg0) {       tr = new TextRenderer(new java.awt.Font("Verdana", java.awt.Font.PLAIN, 10), true, false, null, false);       tr.setColor(0,0,0,1);    }    public void reshape(GLAutoDrawable arg0, int arg1, int arg2, int arg3, int arg4) {       width = arg3;       height = arg4;       GL gl = arg0.getGL();       gl.glViewport(0, 0, width, height);       gl.glMatrixMode(GL.GL_PROJECTION);       gl.glLoadIdentity();       gl.glOrtho(0.0, 800, 0.0, 200, -100.0, 100.0);       gl.glMatrixMode(GL.GL_MODELVIEW);       gl.glLoadIdentity();    }    public void displayChanged(GLAutoDrawable arg0, boolean arg1, boolean arg2) {}     }

[Ken Russell]

ok, here is a testcase, that produces the artifacts with RC5:

Thanks. Filed and fixed Issue 324. Fix will be present in tomorrow's 1.1.1-rc6 build.

[emzic]

yes, it is fixed in RC6. thank you very much!

edit: could the DefaultRenderDelegate class in the TextRender class be made static and public so that we can also use it with mipmapping?
thanks!

edit2: i just tried out mipmapping and after a while the text instantly changed to a very blurry and unreadable version. i couldnt reproduce it yet, but if i can i will post a testcase.
here is a screenshot:

[Ken Russell]

edit: could the DefaultRenderDelegate class in the TextRender class be made static and public so that we can also use it with mipmapping?
thanks!

Done. It was not possible to promote 1.1.1-rc6 today, so tomorrow's build will be 1.1.1-rc6 and will contain this change too.

edit2: i just tried out mipmapping and after a while the text instantly changed to a very blurry and unreadable version. i couldnt reproduce it yet, but if i can i will post a testcase.

No ideas, but please post or file a bug if you can come up with a test case.

[delt0r]

I just tried moving from jogl 1.1.0 to 1.1.1 under linux. Unfortunately my system (SuSE 10.0 64bit)  at work is using glib-2.3.5. Hence does not work. Are there builds agaist other glib versions?

[Ken Russell]

Sorry, not for 64-bit. You can use the 32-bit binaries, which are built against glibc-2.3, with a 32-bit JVM on your system.

[emzic]

i still couldnt reproduce the above artefacts, but it has happened a couple more times since then. all i can say is that it  always happened after i have rendered A LOT of text.

[Ken Russell]

JSR-231 1.1.1 release candidate 6 has been released. This release fixes VBO-related issues related to the new TextRenderer, and adds a non-VBO code path for older machines. It also includes an excellent patch from krisher on java.net for longstanding multi-screen issues on X11 platforms. The JNLP extension has been updated:

1	http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp

and a stable JNLP extension file for this release has been posted:

1	http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1-rc6/webstart/jogl.jnlp

Please try the new release and post if you see any problems.