Ubuntu Edgy, ATI driver and Java2D rendering pipeline, the new headache

I think the title is pretty expressive. Finally, I updated my system from Dapper to Edgy. After that, I updated my ATI drivers to the last version following the method 2 of:

How to install Graphics Driver (ATI)
and
Method 2: Install the 8.35.5 Driver Manually

Once finallized all seems ok.

> fglrxinfo 
display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI MOBILITY RADEON 9600/9700 Series
OpenGL version string: 2.0.6400 (8.35.5)

The problems comes with Java. To not duplicate my job (and spend more time) I put here a link to the post at JavaGaming.org (http://www.javagaming.org/forums/index.php?topic=16421.0) and also a copy of the test:

I spend the last day looking for some answer but I only found a similar problem in another post (http://www.mail-archive.com/java2d-interest@capra.eng.sun.com/msg03962.html).

Recently I updated my system from Ubuntu Dapper to Edgy and from ATI 8.26.x driver version to 8.35.5.

> fglrxinfo
display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI MOBILITY RADEON 9600/9700 Series
OpenGL version string: 2.0.6400 (8.35.5)

Also I have JDK6 and the last release of JOGL (jogl-1.1.0-pre-20070404-linux-i586).
The fgl_glxgears program runs ok

Until now, using JDK6, the old 8.26.x drivers for ATI and JOGL 1.0.0 all was ok in my little application. Now I use JDK6, ATI 8.35.5 and JOGL 1.1.0 (last night build).

I have two problems:

First)
In some part of my code I try to create a PBuffer, first checking with "canCreateGLPbuffer" and then using "GLPbuffer pbuffer = GLDrawableFactory.getFactory().createGLPbuffer(capabilities, null, 1,1, null);"

Until now it works fine but now I recive this:

javax.media.opengl.GLException: pbuffer creation error: glXCreatePbuffer() failed
        at com.sun.opengl.impl.x11.X11PbufferGLDrawable.createPbuffer(X11PbufferGLDrawable.java:162)
        at com.sun.opengl.impl.x11.X11PbufferGLDrawable.(X11PbufferGLDrawable.java:73)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory$3.run(X11GLDrawableFactory.java:320)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.maybeDoSingleThreadedWorkaround(X11GLDrawableFactory.java:670)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.createGLPbuffer(X11GLDrawableFactory.java:327)

Second)
Also (and this I didn't test it in the previous configuration) when I try to execute any JOGL app enabling the opengl pipeline I receive another error.
When I execute demo.gears I get:

> java Gears
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: ATI MOBILITY RADEON 9600/9700 Series
GL_VERSION: 2.0.6400 (8.35.5)

That's ok, my vendor is ATI, but when I execute demo.jgears I get:

> java JGears
java.lang.IllegalArgumentException: input == null!
        at javax.imageio.ImageIO.read(ImageIO.java:1322)
        at JGears.(JGears.java:42)
        at JGears.main(JGears.java:109)
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
GL_VENDOR: Mesa project: www.mesa3d.org
GL_RENDERER: Mesa GLX Indirect
GL_VERSION: 1.2 (1.5 Mesa 6.5.1)

It runs slowly but runs.
What is the problem here?? My vendor is not Mesa.

And finally it I execute with:

> java -Dsun.java2d.opengl=true JGears

or

> java -Dsun.java2d.opengl=true -Dsun.java2d.opengl.fbobject=false JGears

the result is:

exception in QueueFlusher:
javax.media.opengl.GLException: context creation error: couldn't find a suitable frame buffer configuration
        at com.sun.opengl.impl.x11.X11ExternalGLDrawable$Context.create(X11ExternalGLDrawable.java:180)
        at com.sun.opengl.impl.x11.X11ExternalGLDrawable$Context.makeCurrentImpl(X11ExternalGLDrawable.java:123)
        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$2.run(GLJPanel.java:629)
        at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java:203)

Only one more detail. I execute my NetBeans with the options -Dsun.java2d.opengl=true in the netbeans.conf file. Until now it words nice but now the slicers and other components are not well rendered.

If anybody falls here and read this post (and has something about it) please, write a comment.

View frustum and the ilogical way to think

Hi, this is a little post to warn all can read it, about the ilogical way to think on the view frustum.
Suposse you have the bounding box (of an object to be rendered), your camera's frustum and you can calculate if a point is inside the camera's view frustum, then:

• A = All points of the bounding box are inside the frustum.
• B = Some part of the object are in the frustum and must be rendered.

We can say that:

• A-->B, that is, if all points are into the view frustum then the object if completely inside the frustum.

but take care (and remember your old clases of "First-Order Logic"):

• The oposit of A-->B is not (no A -->no B). That is, if all points of the bounding box are outside the view frustum then the object is outside the view frustum. This is false.

Supose you have a bounding box (an object) in the center of the view frustum. If you move the camera to put it in front and very close of the object (mantain it in the center), then left points of the bounding box are out of the frustum by the left plane, and the right points of the bounding box are outside by the right plane. In this situation, and by the above predicate, all points are outside the view frustum but the object would be drawn.

The right oposite proposition for A-->B is "not (A-->B)" or "not (no A or B)" or "A and no B", and this a very different thing than the previous and erroneous definition.

Finally (thanks Brandon) the right to think to know when to draw a object because it is present in the camera view frustum is (or could be):

• If all points of the bounding box are inside the frustum, then the object is completely inside the frustum and must be render,
• if all points are outside by the left plane, or all points are outside by the right plane, etc, then the object is completely outside the frustum and must not be drawn.
• other cases, portions of the object intersects with the view frustum and can be drawn.
  

Improving performance with display lists

Recently I have been working with shapefiles to add support for it in The Balloon Project. Thanks to the GeoTools I can read the format easyly and render it as line loops (GL_LINE_LOOP).
Initially I was using the brute force for rendering, that is, all points in the window are calculate every time they are going to be rendered. They work for polygons with few points and textures (tile images), but when a shapefile with a thousand of points appears in the scene the brute force is not a good solution.
For this, I change some code and now I am using display list in all my renderable object. The performance has increased surprising in my latpop even with a shapefile.