gl4java-usergroup

Re: [gl4java-usergroup] Texture updates

[Kenneth B. R. <kbr...@al...>]

> What is the quickest way of updating a texture (not swapping) with Graphics 
> or Graphics2D like operations with GL4Java?

If you can render the texture to the screen in your application
then you can read back the framebuffer to get hardware
acceleration in texture drawing operations. See Hans Kohling
Pedersen's SIGGRAPH papers on texturing implicit surfaces from a
few years back. If you need offscreen updates of the texture, you
are probably best off doing software rasterization into a
java.nio Buffer, at least until pbuffers have widespread support.

Re: [gl4java-usergroup] nio buffers

[Kenneth B. R. <kbr...@al...>]

> I would like to have an applet run in both 1.1 and 1.4 and that's the reason 
> I ask. When using display lists, the vertex data buffers are copied, and I 
> would presume that it doesn't matter what method you use (except the nasty 
> GL4Java implementation you descibe).

I recommend writing an application instead of an applet and
deploying it with Java Web Start (and ignoring 1.1.x
compatibility). There are no browser compatibility issues with
JWS, but I have seen plenty of compatibility problems with
applets, even between Netscape and IE.

> > Direct buffers provide additional speedups. See the NVidia
> > VertexArrayRange demo in the GL4Java demos
> > (demos/NVidia/VertexArrayRange.java). This demo illustrates that
> > the same factor of two speedup available to C programs using the
> > NVidia vertex_array_range extension is now available to Java
> > programming language programs. The same *binary* runs on
> > GNU/Linux and Windows, and will soon run on Mac OS X.
> 
> But this only applies for dynamic geometry, right?

Not necessarily. You don't have to update the data in the vertex
arrays every frame.

> > Finally, the Grand Canyon demo illustrates that memory-mapping in
> > texture data is now possible, providing speed improvements and a
> > decrease in application footprint.
> 
> I'm not sure what you mean by memory-mapping textures, is it also something 
> with dynamic textures (like avi textures)?

What I meant is sending the texture data from disk directly to
OpenGL without needing to read it into an auxiliary data buffer.
This requires the texture to be in "raw" format (typically
uncompressed and with no file format.)

Re: [gl4java-usergroup] nio buffers

[Kenneth B. R. <kbr...@al...>]

> GL4Java supports nio buffers with 1.4, but I'm unsure where exaclty they 
> increase performance. My guess that they speed up when you write to a 
> VertexBuffer, but not when you have static geometry data (i.e. 
> vertex/color/tex buffers drawn with glDrawElements in a Display List)

First and foremost, direct buffers fix a longstanding problem in
how certain OpenGL routines are accessed. In particular, the
client-side routines like glVertexPointer require the passed
pointer to not move in memory; before JDK 1.4, the only way to
portably implement this was to copy the vertex data out of the
heap. This copying imposes so much overhead that GL4Java actually
implements something incorrect, which is to hold onto the result
of a JNI GetPrimitiveArrayCritical call outside the
Get/ReleaseCritical block. In short, there was no efficient and
correct way to implement these routines before 1.4, and calling
glVertexPointer(..., float[] ptr) is not suitable for production
code as it opens up the possibility of crashes.

Direct buffers provide additional speedups. See the NVidia
VertexArrayRange demo in the GL4Java demos
(demos/NVidia/VertexArrayRange.java). This demo illustrates that
the same factor of two speedup available to C programs using the
NVidia vertex_array_range extension is now available to Java
programming language programs. The same *binary* runs on
GNU/Linux and Windows, and will soon run on Mac OS X.

Finally, the Grand Canyon demo illustrates that memory-mapping in
texture data is now possible, providing speed improvements and a
decrease in application footprint.

[gl4java-usergroup] nio buffers

[Elias N. <na...@od...>]

GL4Java supports nio buffers with 1.4, but I'm unsure where exaclty they 
increase performance. My guess that they speed up when you write to a 
VertexBuffer, but not when you have static geometry data (i.e. 
vertex/color/tex buffers drawn with glDrawElements in a Display List)

 - elias naur

[gl4java-usergroup] Texture updates

[Elias N. <na...@od...>]

What is the quickest way of updating a texture (not swapping) with Graphics 
or Graphics2D like operations with GL4Java?

[gl4java-usergroup] glXGetCurrentContext and NVidia Linux drivers

[Kenneth B. R. <kbr...@al...>]

I received a bug report about an application I have on-line not
working with the latest NVidia Linux drivers due to the known
crash in glXGetCurrentContext. Has this been worked around yet?
If not, could we release a 2.8.3.0 which has the calls to this
routine removed?

Re: [gl4java-usergroup] GL4Java hanging at startup

[Mark M. <pat...@lm...>]

Hi Elias,

We also struggled with getting all the calls in just the right order to make GL4Java
happy (or any Java binding for OpenGL for that matter). Here is what I learned....

There are several basic rules of the game you have to follow when making an app like
this.
1) Create your Frame (parent component)
2) Create a class "Foo" that inherits from Panel (not necessary, but I like this
approach)
3) In "Foo" define a member variable of type GLDrawable (this will hold the
GLAnimCanvas)
4) In "Foo" define your capabilities, then create the GLAnimCanvas (ALWAYS, ALWAYS use
the GLDrawableFactory.getFactory() as you did below)
5) Add the GLDrawable to the LayoutManager in "Foo"
6) Create a class "Bar" that implements GLEventListener
7) Add "Bar" as the GLEventListener for your GLDrawable
8) Now make your Frame, Panel, GLDrawable all visible with setVisible(true)

**NOTE: Once the components become visible, the GLAnimCanvas will receive its first
"display()" call through a GLEvent. When this first display occurs, I believe that
GL4Java finally makes the GLContext (OpenGL state machine). NOW, and only now will the
context be non-null.

9) Finally, you are allow to call getGLContext().gljMakeCurrent(), OR gl.gl****()

** NOTE: If you intend to make display list before the GLDrawable is visible (and
before the GLContext is created), then don't! ;-) We learned this the hard way. Put
your display list creating in the init() method of the GLEventListener. This init()
method gets called after the components are visible and the GLContext is created and
ready to be used.

Hope this helps.

-mark


Elias Naur wrote:

> Hi,
>
> I've recently begun using GL4Java, but I have run into problems with Gl4Java
> sometimes (~ every 10 times) hanging  at startup, my startup code looks like
> this
>
>         frame.setVisible(true);
>         GLCapabilities caps = new GLCapabilities(true, false, true, 0, 0, 0,
> 0, 0);
>         canvas = GLDrawableFactory.getFactory().createGLAnimCanvas(caps,
> Globals.VIEW_WIDTH, Globals.VIEW_HEIGHT);
>         canvas.setUseRepaint(false);
>         canvas.setUseFpsSleep(false);
>         canvas.setUseYield(false);
>         canvas.addGLEventListener(renderer);
>         frame.add(canvas, BorderLayout.CENTER);
>         frame.pack();
>
>         canvas.requestFocus();
>         canvas.start();
>
> If I move the line frame.sertVisible(true) further down (e.g. after
> canvas.start()), it hangs less often. the thread dump while hanging looks
> like this:Full thread dump Java HotSpot(TM) Client VM (1.4.0-b92 mixed mode):
>
> "AWT-EventQueue-0" prio=1 tid=0x0x81d2cf0 nid=0x2577 runnable
> [4cee6000..4cee686c]
>         at gl4java.GLContext.openOpenGLNative(Native Method)
>         at gl4java.GLContext.gljInit(GLContext.java:1996)
>         - locked <0x441426a0> (a gl4java.GLContext)
>         at gl4java.GLContext.createGLContext(GLContext.java:1942)
>         at gl4java.GLContext.<init>(GLContext.java:1161)
>         at gl4java.GLContext.<init>(GLContext.java:1251)
>         at gl4java.awt.GLCanvas.paint(GLCanvas.java:444)
>         at sun.awt.RepaintArea.paint(RepaintArea.java:180)
>         at sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:339)
>         at java.awt.Component.dispatchEventImpl(Component.java:3586)
>         at java.awt.Component.dispatchEvent(Component.java:3367)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
>         at
> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
>         at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
>         at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
>         at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
>
> "Thread-1" daemon prio=1 tid=0x0x81d53b8 nid=0x2576 waiting on monitor
> [4ce65000..4ce6586c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x44170450> (a java.util.TaskQueue)
>         at java.util.TimerThread.mainLoop(Timer.java:429)
>         - locked <0x44170450> (a java.util.TaskQueue)
>         at java.util.TimerThread.run(Timer.java:382)
>
> "AWT-Motif" daemon prio=1 tid=0x0x81c2ef8 nid=0x2575 waiting for monitor
> entry [4cde4000..4cde486c]
>         at sun.awt.motif.MToolkit.run(Native Method)
>         at java.lang.Thread.run(Thread.java:536)
>
> "AWT-Shutdown" prio=1 tid=0x0x819d550 nid=0x2574 waiting on monitor
> [4cd63000..4cd6386c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x4461a478> (a java.lang.Object)
>         at java.lang.Object.wait(Object.java:426)
>         at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
>         - locked <0x4461a478> (a java.lang.Object)
>         at java.lang.Thread.run(Thread.java:536)
>
> "Signal Dispatcher" daemon prio=1 tid=0x0x807b880 nid=0x2572 waiting on
> monitor [0..0]
>
> "Finalizer" daemon prio=1 tid=0x0x8074478 nid=0x256f waiting on monitor
> [4c2f2000..4c2f286c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x445ef168> (a java.lang.ref.ReferenceQueue$Lock)
>         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
>         - locked <0x445ef168> (a java.lang.ref.ReferenceQueue$Lock)
>         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
>         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
>
> "Reference Handler" daemon prio=1 tid=0x0x8073830 nid=0x256e waiting on
> monitor [4c271000..4c27186c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x445ef1d0> (a java.lang.ref.Reference$Lock)
>         at java.lang.Object.wait(Object.java:426)
>         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113)
>         - locked <0x445ef1d0> (a java.lang.ref.Reference$Lock)
>
> "main" prio=1 tid=0x0x8051558 nid=0x256b waiting for monitor entry
> [bfffd000..bfffd718]
>         at sun.awt.motif.MComponentPeer.pReshape(Native Method)
>         at sun.awt.motif.MComponentPeer.setBounds(MComponentPeer.java:739)
>         at java.awt.Component.reshape(Component.java:1685)
>         - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
>         at java.awt.Component.setBounds(Component.java:1644)
>         at java.awt.BorderLayout.layoutContainer(BorderLayout.java:683)
>         - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
>         at java.awt.Container.layout(Container.java:835)
>         at java.awt.Container.doLayout(Container.java:825)
>         at java.awt.Container.validateTree(Container.java:903)
>         at java.awt.Container.validate(Container.java:878)
>         - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
>         at java.awt.Window.pack(Window.java:418)
>         at life3d.Main.run(Main.java:73)
>         at life3d.Main.main(Main.java:102)
>
> "VM Thread" prio=1 tid=0x0x80706b0 nid=0x256d runnable
>
> "VM Periodic Task Thread" prio=1 tid=0x0x807a390 nid=0x2570 waiting on monitor
> "Suspend Checker Thread" prio=1 tid=0x0x807ae08 nid=0x2571 runnable
>
> it looks like that every time (hang in openOpenGLNative())
>
> I use red hat linux 7.2 with 2.4.17 kernel and nvidia drivers 2314. JVM
> version is 1.4.0 and GL4Java version is 2.8.2.0
>
> someone has advice?  how can I pinpoint it even further? i.e. how can I
> easily tell in which line in openOpenGLNative my app hangs?
>
>  - Elias Naur
>
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

Re: [gl4java-usergroup] GL4Java hanging at startup

[Jacob M. <ja...@ma...>]

Hi Elias,

Nice to see that you are giving gl4java a try :)

What do you mean when you say your code hangs?
Does the first frame show or are nothing shown at all?

Be sure to set a layout before setVisible().
Also, calling pack() after
setVisible() does not make sense. Here is a snippet
from the code I use (I have no crash trouble).

(The frame is a Swing JFrame in the case below)
-------
    f.getContentPane().setLayout(new BorderLayout());
    f.pack();
    Insets i = f.getInsets();
    f.setBounds(0, 0, 640 + i.right + i.left, 480 + i.bottom + i.top);

    Dimension d = f.getSize();
    GLCapabilities caps = new GLCapabilities();
    GLAnimCanvas canvas = GLDrawableFactory.getFactory()
                         .createGLAnimCanvas(caps, d.width, d.height);
    canvas.addGLEventListener(demo); // my event handler
    canvas.setUseRepaint(false);
    canvas.setUseFpsSleep(false);
    canvas.setUseYield(false);

    canvas.requestFocus();
    f.getContentPane().add("Center", canvas);
    canvas.start();

    f.setVisible(true);
-------

I hope this helps,

Jacob

----- Original Message -----
From: "Elias Naur" <na...@od...>
To: <gl4...@li...>
Sent: Saturday, February 16, 2002 15:01
Subject: [gl4java-usergroup] GL4Java hanging at startup


> Hi,
>
> I've recently begun using GL4Java, but I have run into problems with Gl4Java
> sometimes (~ every 10 times) hanging  at startup, my startup code looks like
> this
>
>         frame.setVisible(true);
>         GLCapabilities caps = new GLCapabilities(true, false, true, 0, 0, 0,
> 0, 0);
>         canvas = GLDrawableFactory.getFactory().createGLAnimCanvas(caps,
> Globals.VIEW_WIDTH, Globals.VIEW_HEIGHT);
>         canvas.setUseRepaint(false);
>         canvas.setUseFpsSleep(false);
>         canvas.setUseYield(false);
>         canvas.addGLEventListener(renderer);
>         frame.add(canvas, BorderLayout.CENTER);
>         frame.pack();
>
>         canvas.requestFocus();
>         canvas.start();
>
> If I move the line frame.sertVisible(true) further down (e.g. after
> canvas.start()), it hangs less often. the thread dump while hanging looks
> like this:Full thread dump Java HotSpot(TM) Client VM (1.4.0-b92 mixed mode):
>
> "AWT-EventQueue-0" prio=1 tid=0x0x81d2cf0 nid=0x2577 runnable
> [4cee6000..4cee686c]
>         at gl4java.GLContext.openOpenGLNative(Native Method)
>         at gl4java.GLContext.gljInit(GLContext.java:1996)
>         - locked <0x441426a0> (a gl4java.GLContext)
>         at gl4java.GLContext.createGLContext(GLContext.java:1942)
>         at gl4java.GLContext.<init>(GLContext.java:1161)
>         at gl4java.GLContext.<init>(GLContext.java:1251)
>         at gl4java.awt.GLCanvas.paint(GLCanvas.java:444)
>         at sun.awt.RepaintArea.paint(RepaintArea.java:180)
>         at sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:339)
>         at java.awt.Component.dispatchEventImpl(Component.java:3586)
>         at java.awt.Component.dispatchEvent(Component.java:3367)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
>         at
>
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:1
90)
>         at
>
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144
)
>         at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
>         at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
>
> "Thread-1" daemon prio=1 tid=0x0x81d53b8 nid=0x2576 waiting on monitor
> [4ce65000..4ce6586c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x44170450> (a java.util.TaskQueue)
>         at java.util.TimerThread.mainLoop(Timer.java:429)
>         - locked <0x44170450> (a java.util.TaskQueue)
>         at java.util.TimerThread.run(Timer.java:382)
>
> "AWT-Motif" daemon prio=1 tid=0x0x81c2ef8 nid=0x2575 waiting for monitor
> entry [4cde4000..4cde486c]
>         at sun.awt.motif.MToolkit.run(Native Method)
>         at java.lang.Thread.run(Thread.java:536)
>
> "AWT-Shutdown" prio=1 tid=0x0x819d550 nid=0x2574 waiting on monitor
> [4cd63000..4cd6386c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x4461a478> (a java.lang.Object)
>         at java.lang.Object.wait(Object.java:426)
>         at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
>         - locked <0x4461a478> (a java.lang.Object)
>         at java.lang.Thread.run(Thread.java:536)
>
> "Signal Dispatcher" daemon prio=1 tid=0x0x807b880 nid=0x2572 waiting on
> monitor [0..0]
>
> "Finalizer" daemon prio=1 tid=0x0x8074478 nid=0x256f waiting on monitor
> [4c2f2000..4c2f286c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x445ef168> (a java.lang.ref.ReferenceQueue$Lock)
>         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
>         - locked <0x445ef168> (a java.lang.ref.ReferenceQueue$Lock)
>         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
>         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
>
> "Reference Handler" daemon prio=1 tid=0x0x8073830 nid=0x256e waiting on
> monitor [4c271000..4c27186c]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x445ef1d0> (a java.lang.ref.Reference$Lock)
>         at java.lang.Object.wait(Object.java:426)
>         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113)
>         - locked <0x445ef1d0> (a java.lang.ref.Reference$Lock)
>
> "main" prio=1 tid=0x0x8051558 nid=0x256b waiting for monitor entry
> [bfffd000..bfffd718]
>         at sun.awt.motif.MComponentPeer.pReshape(Native Method)
>         at sun.awt.motif.MComponentPeer.setBounds(MComponentPeer.java:739)
>         at java.awt.Component.reshape(Component.java:1685)
>         - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
>         at java.awt.Component.setBounds(Component.java:1644)
>         at java.awt.BorderLayout.layoutContainer(BorderLayout.java:683)
>         - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
>         at java.awt.Container.layout(Container.java:835)
>         at java.awt.Container.doLayout(Container.java:825)
>         at java.awt.Container.validateTree(Container.java:903)
>         at java.awt.Container.validate(Container.java:878)
>         - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
>         at java.awt.Window.pack(Window.java:418)
>         at life3d.Main.run(Main.java:73)
>         at life3d.Main.main(Main.java:102)
>
> "VM Thread" prio=1 tid=0x0x80706b0 nid=0x256d runnable
>
> "VM Periodic Task Thread" prio=1 tid=0x0x807a390 nid=0x2570 waiting on monitor
> "Suspend Checker Thread" prio=1 tid=0x0x807ae08 nid=0x2571 runnable
>
> it looks like that every time (hang in openOpenGLNative())
>
> I use red hat linux 7.2 with 2.4.17 kernel and nvidia drivers 2314. JVM
> version is 1.4.0 and GL4Java version is 2.8.2.0
>
> someone has advice?  how can I pinpoint it even further? i.e. how can I
> easily tell in which line in openOpenGLNative my app hangs?
>
>  - Elias Naur
>
>
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>

[gl4java-usergroup] GL4Java hanging at startup

[Elias N. <na...@od...>]

Hi,

I've recently begun using GL4Java, but I have run into problems with Gl4Java 
sometimes (~ every 10 times) hanging  at startup, my startup code looks like 
this

        frame.setVisible(true);
        GLCapabilities caps = new GLCapabilities(true, false, true, 0, 0, 0, 
0, 0);
        canvas = GLDrawableFactory.getFactory().createGLAnimCanvas(caps, 
Globals.VIEW_WIDTH, Globals.VIEW_HEIGHT);
        canvas.setUseRepaint(false);
        canvas.setUseFpsSleep(false);
        canvas.setUseYield(false);
        canvas.addGLEventListener(renderer);
        frame.add(canvas, BorderLayout.CENTER);
        frame.pack();
        
        canvas.requestFocus();
        canvas.start();

If I move the line frame.sertVisible(true) further down (e.g. after 
canvas.start()), it hangs less often. the thread dump while hanging looks 
like this:Full thread dump Java HotSpot(TM) Client VM (1.4.0-b92 mixed mode):

"AWT-EventQueue-0" prio=1 tid=0x0x81d2cf0 nid=0x2577 runnable 
[4cee6000..4cee686c]
        at gl4java.GLContext.openOpenGLNative(Native Method)
        at gl4java.GLContext.gljInit(GLContext.java:1996)
        - locked <0x441426a0> (a gl4java.GLContext)
        at gl4java.GLContext.createGLContext(GLContext.java:1942)
        at gl4java.GLContext.<init>(GLContext.java:1161)
        at gl4java.GLContext.<init>(GLContext.java:1251)
        at gl4java.awt.GLCanvas.paint(GLCanvas.java:444)
        at sun.awt.RepaintArea.paint(RepaintArea.java:180)
        at sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:339)
        at java.awt.Component.dispatchEventImpl(Component.java:3586)
        at java.awt.Component.dispatchEvent(Component.java:3367)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
        at 
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
        at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
        at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
        at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)

"Thread-1" daemon prio=1 tid=0x0x81d53b8 nid=0x2576 waiting on monitor 
[4ce65000..4ce6586c]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44170450> (a java.util.TaskQueue)
        at java.util.TimerThread.mainLoop(Timer.java:429)
        - locked <0x44170450> (a java.util.TaskQueue)
        at java.util.TimerThread.run(Timer.java:382)

"AWT-Motif" daemon prio=1 tid=0x0x81c2ef8 nid=0x2575 waiting for monitor 
entry [4cde4000..4cde486c]
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Thread.java:536)

"AWT-Shutdown" prio=1 tid=0x0x819d550 nid=0x2574 waiting on monitor 
[4cd63000..4cd6386c]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x4461a478> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:426)
        at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
        - locked <0x4461a478> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:536)

"Signal Dispatcher" daemon prio=1 tid=0x0x807b880 nid=0x2572 waiting on 
monitor [0..0]

"Finalizer" daemon prio=1 tid=0x0x8074478 nid=0x256f waiting on monitor 
[4c2f2000..4c2f286c]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x445ef168> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <0x445ef168> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=1 tid=0x0x8073830 nid=0x256e waiting on 
monitor [4c271000..4c27186c]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x445ef1d0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:426)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113)
        - locked <0x445ef1d0> (a java.lang.ref.Reference$Lock)

"main" prio=1 tid=0x0x8051558 nid=0x256b waiting for monitor entry 
[bfffd000..bfffd718]
        at sun.awt.motif.MComponentPeer.pReshape(Native Method)
        at sun.awt.motif.MComponentPeer.setBounds(MComponentPeer.java:739)
        at java.awt.Component.reshape(Component.java:1685)
        - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
        at java.awt.Component.setBounds(Component.java:1644)
        at java.awt.BorderLayout.layoutContainer(BorderLayout.java:683)
        - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
        at java.awt.Container.layout(Container.java:835)
        at java.awt.Container.doLayout(Container.java:825)
        at java.awt.Container.validateTree(Container.java:903)
        at java.awt.Container.validate(Container.java:878)
        - locked <0x44619fb0> (a java.awt.Component$AWTTreeLock)
        at java.awt.Window.pack(Window.java:418)
        at life3d.Main.run(Main.java:73)
        at life3d.Main.main(Main.java:102)

"VM Thread" prio=1 tid=0x0x80706b0 nid=0x256d runnable

"VM Periodic Task Thread" prio=1 tid=0x0x807a390 nid=0x2570 waiting on monitor
"Suspend Checker Thread" prio=1 tid=0x0x807ae08 nid=0x2571 runnable

it looks like that every time (hang in openOpenGLNative())

I use red hat linux 7.2 with 2.4.17 kernel and nvidia drivers 2314. JVM 
version is 1.4.0 and GL4Java version is 2.8.2.0

someone has advice?  how can I pinpoint it even further? i.e. how can I 
easily tell in which line in openOpenGLNative my app hangs?

 - Elias Naur

Re: [gl4java-usergroup] GC Bug

[Pepijn V. E. <pep...@lu...>]

Thanks, I got the code generation working now.
The patches I've made fix the memory corruption bug for the tesselator 
and allow multiple tesselator objects with different callbacks to be 
used. The callback fix will only work in a single threaded environment, 
but I guess for the moment this isn't really a problem.
Should I send you these fixes? If so, in how should I package it? 
(diffs, entire source tree, ...) (Sorry, I'm new to the open source 
development concept ;) )

Pepijn Van Eeckhoudt

Sven Goethel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
>>I checked those scripts, but the only thing they do is filter out the 
>>lines containing GL[U]API and replace some strings. I ran the prepare 
>>script again myself and glGetString is still in gl-proto-auto.orig. 
>>However in gl-proto-auto.orig.h there's no sign of glGetString. So my 
>>guess is you have to manually remove the functions that shouldn't be 
>>autogenerated... Can anyone confirm this? If it's so, I'll write a small 
>>script that reads a file containing the functions to be removed and 
>>removes these automatically from the .orig file.
>>
> 
> kbr wrote:
> Sven can confirm this 100% but I'll suggest to please write such
> a script as it doesn't appear (to me) to exist yet.
> 
> i response:
> 
> well the directory (within C2J)
> 	mesa40-header
> is _ONLY_ for archive purpose, and to show
> how and where we do got all these *orig.h files !
> 
> so, if you like to manually implement any functions,
> you have to remove them form the *orig.h files,
> which will C2J cause not to generate the glue ;-)
> 
> then implement them manually within the appropiate
> manual/* files (add your code to the existing ones, or create 
> new files - add a recipe into makefile) ..
> 
> thats all
> 
> btw: sorry for my off time, but i havd (and still have)
> email difficulties.
> 
> would somebody be so kind and send me an email archive 
> of the gl4java lists from 2002/02/26 - TODAY 
> in the usual unix format ?
> thanxs in advance.
>  
> 
> - -- 
> health & wealth
> mailto:sgo...@ja...
> www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
> voice : +49-521-2399440 ; fax : +49-521-2399442
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE8aeGQHdOA30NoFAARApN6AJ9diKFQKz3KpFWlvIeKz2Rx1wxLEQCeLJos
> DQxleqxHgd/XxMTvzTJYUKs=
> =ov3o
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 
> 

RE: [gl4java-usergroup] GC Bug

[Sven G. <sgo...@t-...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> I checked those scripts, but the only thing they do is filter out the 
> lines containing GL[U]API and replace some strings. I ran the prepare 
> script again myself and glGetString is still in gl-proto-auto.orig. 
> However in gl-proto-auto.orig.h there's no sign of glGetString. So my 
> guess is you have to manually remove the functions that shouldn't be 
> autogenerated... Can anyone confirm this? If it's so, I'll write a small 
> script that reads a file containing the functions to be removed and 
> removes these automatically from the .orig file.

kbr wrote:
Sven can confirm this 100% but I'll suggest to please write such
a script as it doesn't appear (to me) to exist yet.

i response:

well the directory (within C2J)
	mesa40-header
is _ONLY_ for archive purpose, and to show
how and where we do got all these *orig.h files !

so, if you like to manually implement any functions,
you have to remove them form the *orig.h files,
which will C2J cause not to generate the glue ;-)

then implement them manually within the appropiate
manual/* files (add your code to the existing ones, or create 
new files - add a recipe into makefile) ..

thats all

btw: sorry for my off time, but i havd (and still have)
email difficulties.

would somebody be so kind and send me an email archive 
of the gl4java lists from 2002/02/26 - TODAY 
in the usual unix format ?
thanxs in advance.
 

- -- 
health & wealth
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440 ; fax : +49-521-2399442
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8aeGQHdOA30NoFAARApN6AJ9diKFQKz3KpFWlvIeKz2Rx1wxLEQCeLJos
DQxleqxHgd/XxMTvzTJYUKs=
=ov3o
-----END PGP SIGNATURE-----

[gl4java-usergroup] sorry - i am back in asap

[Sven G. <sgo...@ja...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dear gl4java users,

because of email difficulties since january 22nd or 26th 2002,
i cannot receive many emails from many sources, e.g. our gl4java list.

i do communicate now with my provider, so things may be fixed asap

cheers, sven


- -- 
health & wealth
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440 ; fax : +49-521-2399442
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8abWrHdOA30NoFAARAuiKAKCHG0BQA2q4pecMIBvlNufl48ZJeACfciYF
Hk8x/5ZgFepXvphUY6o9GdQ=
=Zkmn
-----END PGP SIGNATURE-----

[gl4java-usergroup] test (please ignore)

[Sven G. <sgo...@ja...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

test  - please ignore
- -- 
health & wealth
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440 ; fax : +49-521-2399442
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8aaf6HdOA30NoFAARArHcAJ9JCHHAx2KYU9yPxeTgRlXm7hzaFQCeKv0H
agDhhB0QQWXyiPnPHio0iFg=
=l/S5
-----END PGP SIGNATURE-----

[gl4java-usergroup] NoClassDefFoundError

[Save T. W. <sav...@op...>]

I'm tyring to bring up glDemosCvs.html in IE 5.5.  I'm getting a:  "Exception 
java.lang.NoClassDefFoundError:  gl4java/awt/GLAnimCanvas".  I'm using java 
1.4rcs and IE is using the 1.4 jre.  I've edited the policy files,the 
necessary jar files are in the lib/ext directory and the .dlls are in jre\bin 
(which is where java.dll is).  Any ideas?  I'm running Win2k.

Thanks!

Re: [gl4java-usergroup] native code excepting when drawing over 39000 vertices

[Kenneth B. R. <kbr...@al...>]

> >If i remember well, there is a maximum limit to the number of vertices you
> >can pass in an array. 39000 may be over ?
> >OpenGL has some function (glGet...) to get the limit, you should check it.
> >
> perhaps you're right, but I can't find any glGet.. Method to get the 
> limit, and I wonder why milksahpe can display it  without problems, 
> because it uses OpenGL to render the objects..
> 
> so I would be very lucky if you or s.o. else could tell me the complete 
> method name.

It looks like glGet(GL_MAX_ELEMENTS_VERTICES) is what you
need. However, this glGet seems to only be associated with
glDrawRangeElements, not glDrawArrays.

OpenGL for Java does almost no additional work beyond calling
down to OpenGL; however, it is definitely possible to crash the
JVM in the same way it is possible to crash a C program using
OpenGL.

Re: [gl4java-usergroup] native code excepting when drawing over 39000 vertices

[Michael N. <ze...@mo...>]

Hi Jiba,,

>
>If i remember well, there is a maximum limit to the number of vertices you
>can pass in an array. 39000 may be over ?
>OpenGL has some function (glGet...) to get the limit, you should check it.
>
perhaps you're right, but I can't find any glGet.. Method to get the 
limit, and I wonder why milksahpe can display it  without problems, 
because it uses OpenGL to render the objects..

so I would be very lucky if you or s.o. else could tell me the complete 
method name.


greetings
 -Michael Nischt

Re: [gl4java-usergroup] native code excepting when drawing over 39000 vertices

[Jiba <Jea...@im...>]

On 2002.02.12 12:03:38 +0000 Michael Nischt wrote:
> Hi Kenneth,
> 
> >
> >It is likely a bug in your application. Try compiling your DLL
> >with debug information and running your program in the Visual C++
> >debugger.
> >
> 
> Sorry my mail might be confusing:
> I don't use my own native code, the excpetion must be in gl4java libs. I 
> hoped it would be clear with the error log containing:
> 
> ..
> Current Java thread:
>    at gl4java.GLFunc14JauJNI.glDrawArrays(Native Method)
> ..
> 
> 
> greetings
>  -Michael Nischt

If i remember well, there is a maximum limit to the number of vertices you
can pass in an array. 39000 may be over ?
OpenGL has some function (glGet...) to get the limit, you should check it.

Jiba

Re: [gl4java-usergroup] native code excepting when drawing over 39000 vertices

[Michael N. <ze...@mo...>]

Hi Kenneth,

>
>It is likely a bug in your application. Try compiling your DLL
>with debug information and running your program in the Visual C++
>debugger.
>

Sorry my mail might be confusing:
I don't use my own native code, the excpetion must be in gl4java libs. I 
hoped it would be clear with the error log containing:

..
Current Java thread:
   at gl4java.GLFunc14JauJNI.glDrawArrays(Native Method)
..


greetings
 -Michael Nischt

Re: [gl4java-usergroup] native code excepting when drawing over 39000 vertices

[Kenneth B. R. <kbr...@al...>]

> my programm shut down when I try drawing high-poly models.
> If the model only has about 10000 polys everything is fine, but with a 
> test model consisting of 39538 vertices the program cause an exception 
> in native code.
> 
> I'm using glVertexPointer with all vertices in one FloatBuffer.
> 
> Does anyone have/had the same problem ?

It is likely a bug in your application. Try compiling your DLL
with debug information and running your program in the Visual C++
debugger.

[gl4java-usergroup] native code excepting when drawing over 39000 vertices

[Michael N. <ze...@mo...>]

hi all,
my programm shut down when I try drawing high-poly models.
If the model only has about 10000 polys everything is fine, but with a 
test model consisting of 39538 vertices the program cause an exception 
in native code.

I'm using glVertexPointer with all vertices in one FloatBuffer.

Does anyone have/had the same problem ?

greetings
 -Michael Nischt



An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x69535556
Function=[Unknown.]
Library=C:\WINNT\System32\nvoglnt.dll

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.


Current Java thread:
    at gl4java.GLFunc14JauJNI.glDrawArrays(Native Method)
    at net.monoid.gl4java.ms3d.MS3DModel.render(MS3DModel.java:165)
    at MS3DViewer.display(MS3DViewer.java:189)
    at 
gl4java.drawable.utils.GLEventListenerList.sendDisplayEvent(GLEventListenerList.java:52)
    at gl4java.awt.GLCanvas.display(GLCanvas.java:793)
    at gl4java.awt.GLCanvas.sDisplay(GLCanvas.java:715)
    at gl4java.awt.GLAnimCanvas.run(GLAnimCanvas.java:466)
    at java.lang.Thread.run(Thread.java:536)

Dynamic libraries:
0x00400000 - 0x00406000     C:\JDK1.4\bin\java.exe
0x77880000 - 0x77901000     C:\WINNT\System32\ntdll.dll
0x77DA0000 - 0x77DFB000     C:\WINNT\system32\ADVAPI32.dll
0x77E70000 - 0x77F32000     C:\WINNT\system32\KERNEL32.DLL
0x77D30000 - 0x77DA0000     C:\WINNT\system32\RPCRT4.DLL
0x78000000 - 0x78046000     C:\WINNT\system32\MSVCRT.dll
0x6D330000 - 0x6D442000     C:\JDK1.4\jre\bin\client\jvm.dll
0x77E00000 - 0x77E64000     C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7C000     C:\WINNT\system32\GDI32.DLL
0x77540000 - 0x77571000     C:\WINNT\System32\WINMM.dll
0x10000000 - 0x10019000     C:\WINNT\System32\NVDESK32.DLL
0x6D1D0000 - 0x6D1D7000     C:\JDK1.4\jre\bin\hpi.dll
0x6D300000 - 0x6D30D000     C:\JDK1.4\jre\bin\verify.dll
0x6D210000 - 0x6D228000     C:\JDK1.4\jre\bin\java.dll
0x6D320000 - 0x6D32D000     C:\JDK1.4\jre\bin\zip.dll
0x6D000000 - 0x6D0F6000     C:\jdk1.4\jre\bin\awt.dll
0x777F0000 - 0x7780D000     C:\WINNT\System32\WINSPOOL.DRV
0x75DF0000 - 0x75E0A000     C:\WINNT\System32\IMM32.dll
0x77A40000 - 0x77B36000     C:\WINNT\system32\ole32.dll
0x6D180000 - 0x6D1D0000     C:\jdk1.4\jre\bin\fontmanager.dll
0x72810000 - 0x72816000     C:\WINNT\System32\DCIMAN32.dll
0x69500000 - 0x697E2000     C:\WINNT\System32\nvoglnt.dll
0x6E330000 - 0x6E336000     C:\WINNT\System32\INDICDLL.dll
0x63000000 - 0x63014000     C:\WINNT\System32\SynTPFcs.dll
0x77810000 - 0x77817000     C:\WINNT\system32\VERSION.dll
0x75940000 - 0x75946000     C:\WINNT\system32\LZ32.DLL
0x0B300000 - 0x0B36C000     C:\jdk1.4\jre\bin\GL4JavaJauGljJNI14.dll
0x6D230000 - 0x6D235000     C:\JDK1.4\jre\bin\jawt.dll
0x693A0000 - 0x69467000     C:\WINNT\System32\OPENGL32.DLL
0x6F9F0000 - 0x6FA10000     C:\WINNT\System32\GLU32.dll
0x51000000 - 0x51044000     C:\WINNT\System32\DDRAW.dll
0x77910000 - 0x77933000     C:\WINNT\system32\imagehlp.dll
0x72970000 - 0x7299D000     C:\WINNT\system32\DBGHELP.dll
0x68F30000 - 0x68F3B000     C:\WINNT\System32\PSAPI.DLL

Local Time = Tue Feb 12 04:55:14 2002
Elapsed Time = 1
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.0-rc-b91 mixed mode)
#

[gl4java-usergroup] gljDestroy failed (free)

[Michael N. <ze...@mo...>]

hi there,
every time quitting my GL4Java apps, I got the following error Message:

'gljDestroy failed (freee)'

what am I doing wrong ?

greetings
 -Michael Nischt


-------------------------------------------------------------------------=
-----------
display starts with:

if (glj.gljMakeCurrent() =3D=3D false)
    return;


display ends with:

glj.gljSwap();
       =20
glj.gljCheckGL();
       =20
glj.gljFree();


windowClosing starts with:

canvas.stop();
       =20
canvas.cvsDispose();
-------------------------------------------------------------------------=
-----------

Re: [gl4java-usergroup] display and reshape. Possible bug.

[Kenneth B. R. <kbr...@al...>]

> My first gl4java application was written using the old
> model where you derive from GLAnimCanvas. I have
> just ported it to the new model where I just implement
> GLEventListener. It all works fine with one exception:
> 
> For the very first frame display() is called
> before reshape(). Reshape is then called for the second
> frame and all is good. However it is custom in all 
> the OpenGL implementations I have seen to call the
> equivalent of reshape() before any calls to display().
> So I think this is a bug.
> 
> A workaround is simply to call reshape() as the last
> instruction in init().

It looks like I may have introduced this bug with the "automatic"
disabling of AWT thread rendering. There is some tricky logic
inside GLCanvas (which is only enabled when the actual canvas is
a GLAnimCanvas) to cause init(), display(), reshape(), etc. to
always be called on the GLAnimCanvas's internal thread and never
on the AWT event queue thread. This is done for performance and
stability reasons. Because of this logic, the first time a
display() is done (actually sDisplay()) the resize is deferred
for a frame.

Could you send me a small test case illustrating the problem
(i.e., with printlns)?

Re: [gl4java-usergroup] GC Bug

[Kenneth B. R. <kbr...@al...>]

> I checked those scripts, but the only thing they do is filter out the 
> lines containing GL[U]API and replace some strings. I ran the prepare 
> script again myself and glGetString is still in gl-proto-auto.orig. 
> However in gl-proto-auto.orig.h there's no sign of glGetString. So my 
> guess is you have to manually remove the functions that shouldn't be 
> autogenerated... Can anyone confirm this? If it's so, I'll write a small 
> script that reads a file containing the functions to be removed and 
> removes these automatically from the .orig file.

Sven can confirm this 100% but I'll suggest to please write such
a script as it doesn't appear (to me) to exist yet.

Re: [gl4java-usergroup] how to use java lang

[Jacob M. <ja...@ma...>]

Hi Leon,

Jumping into gl4java without any Java knowledge at
all will be hard. I recommend these two sources to
learn some Java:

http://java.sun.com/docs/books/tutorial/

and

http://www.mindview.net/Books/TIJ/

That said, programming gl4java is much like
programming it in C++ with GLUT - but the
local Java GUI is used (AWT/Swing) - but
GUI toolkit is quite simple to use.

Sincerely,
Jacob Marner


> Hi, I'm kinda new to Java, but I have some experience
> of using OpenGL in C/C++. I install the GL4java, but I
> don't know how to run the java code. On the home page
> of GL4java, it mentions that I still can use Visual
> C++ to run the java code. But vc won't recognize the
> file.java. So please let me know how to port the java
> file into Visual C++ and then associate with GL4java.
> 
> Thanx
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 

[gl4java-usergroup] display and reshape. Possible bug.

[Jacob M. <ja...@ma...>]

Hi,

My first gl4java application was written using the old
model where you derive from GLAnimCanvas. I have
just ported it to the new model where I just implement
GLEventListener. It all works fine with one exception:

For the very first frame display() is called
before reshape(). Reshape is then called for the second
frame and all is good. However it is custom in all 
the OpenGL implementations I have seen to call the
equivalent of reshape() before any calls to display().
So I think this is a bug.

A workaround is simply to call reshape() as the last
instruction in init().

------

And then a little tip:

I have noted that many demos do this or something similar:

Dimension ps = applet.getPreferredSize();
  f.setBounds(-100,-100,99,99);
  f.setVisible(true);
  f.setVisible(false);
  f.setVisible(true);
  Insets i = f.getInsets();
  f.setBounds(0,0,
       ps.width+i.left+i.right, 
              ps.height+i.top+i.bottom);
  f.setVisible(true);

Showing the frame seems to be needed to make the insets
be correct. However, I have found that  it can be done simpler
and faster as (I have only tested it with applications not applets):

Dimension ps = applet.getPreferredSize();
f.pack();
Insets i = f.getInsets();
f.setBounds(0,0,
       ps.width+i.left+i.right, 
              ps.height+i.top+i.bottom);
f.setVisible(true);

---------------------

PS: Thanks Kenneth for answering my newbie question
a few days ago. I have since then learned much I feel
that I am quite capable of writing gl4java apps.

Sincerely,
Jacob Marner