gl4java-usergroup

Re: [gl4java-usergroup] GC Bug

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

The problem with the current version of the tesselator isn't a memory 
leak, but a memory corruption problem. In short, if a gc occurs during 
the tesselation of an object (ie while you're calling gluTessVertex) 
there is a possibility that the vertex data is corrupted. This is due to 
the way the passed vertex data is locked and released in the native 
library. If written a fix for this, that automatically releases any 
allocated memory at the right time, but this hasn't been included in 
gl4java yet (at least I don't think so). More detailed explanations can 
be found in the mailinglist archive.

Pepijn Van Eeckhoudt

Mark Montana wrote:
> Does the GL4Java glu tesselator have a memory leak currently? I know that the Magician
> API had a release() method for their tesselator for releasing internal memory allocated
> by the tesselator, but I did not see such a method here.
> 
> In fact, we forgot to call the release() method in our app, and we had a nasty leak that
> took us a while to track down. In fact, we were in danger of losing one of our customers
> over it.
> 
> I am very curious about what arrays the GL4Java tesselator is allocating (vertex
> arrays?) and if it is freeing that memory. One of our graphical objects is tesselated
> every frame (because it changes too frequently to bother with display listing), and that
> becomes a nasty problem for us if the tesselator has a leak. Can anyone shed some light
> for me?
> 
> thanks,
> mark
> 
> Pepijn Van Eeckhoudt wrote:
> 
> 
>>I wrote a simple memory management module that keeps track of the
>>alocated arrays, so they can be released at a later point. I've tested
>>this idea with the tesselation stuff, and it works fine.
>>I've made these changes to the C files in the CNativeCode directory,
>>which isn't ideal (should be autogenerated). Could someone explain to me
>>where I can put my implementations of the
>>Java_gl4java_GLUFunc14JauJNI_gluTessVertex__* functions, so they would
>>appear in the generated c files automatically.
>>
>>thanks,
>>Pepijn Van Eeckhoudt
>>
> 
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 
> 

Re: [gl4java-usergroup] thanks kenneth (was: gleem (OpenGL Extremely Easy-to-Use Manipulators) for Java)

[The P. <ph...@te...>]

Java Webstart rocks.  Thanks for introducing it to me with your GLCanvas
program Kenneth.  GLCanvas allowed me to prove to quickly prove to several
of my bosses that java can do fast OpenGL and WebStart allowed me to
deploy an internal application very painlessly for some not-so-technical
managers.  Before webstart I was getting some serious resistance to 
writing utility apps in java.

So, anyway, thanks.

--physic
ph...@te...

On Wed, 6 Feb 2002, Kenneth B. Russell wrote:

> 
> > but what is even more interesting for me, is how to deploy a own demo using
> > Java Webstart ?
> 
> See the documentation at
> http://java.sun.com/products/javawebstart/ , in particular the
> developers' documentation. Deploying an application is pretty
> simple. One issue is that deploying applications which require
> certain permissions (for example, the ability to load a native
> library) requires code signing, and in order to do this properly
> you need a certificate from Verisign, Thawte, or similar, which
> can run into hundreds of dollars.
> 
> I'm looking into whether this signing can be done once for OpenGL
> for Java, and whether applications using it can be unsigned. If
> you have experience with this then please share with the mailing
> list.
> 
> > And further on, will Webstart also download latest GL4Java version if not
> > exsiting ?
> 
> Yes. Not only that, it will automatically download and install
> the appropriate JRE.
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 

Re: [gl4java-usergroup] GC Bug

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

Does the GL4Java glu tesselator have a memory leak currently? I know that the Magician
API had a release() method for their tesselator for releasing internal memory allocated
by the tesselator, but I did not see such a method here.

In fact, we forgot to call the release() method in our app, and we had a nasty leak that
took us a while to track down. In fact, we were in danger of losing one of our customers
over it.

I am very curious about what arrays the GL4Java tesselator is allocating (vertex
arrays?) and if it is freeing that memory. One of our graphical objects is tesselated
every frame (because it changes too frequently to bother with display listing), and that
becomes a nasty problem for us if the tesselator has a leak. Can anyone shed some light
for me?

thanks,
mark

Pepijn Van Eeckhoudt wrote:

> I wrote a simple memory management module that keeps track of the
> alocated arrays, so they can be released at a later point. I've tested
> this idea with the tesselation stuff, and it works fine.
> I've made these changes to the C files in the CNativeCode directory,
> which isn't ideal (should be autogenerated). Could someone explain to me
> where I can put my implementations of the
> Java_gl4java_GLUFunc14JauJNI_gluTessVertex__* functions, so they would
> appear in the generated c files automatically.
>
> thanks,
> Pepijn Van Eeckhoudt

Re: [gl4java-usergroup] reference problem in GLOffScreenDrawable

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

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

right, thx

will be added within cvs soon

On Sunday 27 January 2002 01:09, nader wrote:
> Hello,
>
> Let me first say thanks (again) for enabling the option to disable all
> debugging output. I am also thankful that you have implemented a more
> straightforward offscreen rendering class.
>
> There is however one problem with it (or what looks like a problem). The
> setSize(Dimension size) method located at line 236 in file
> GLOffScreenDrawable.java is implemented to set the internal size
> (offScrnSize) to the passed in size by reference, not by copying the
> actuall values (width and height). This poses a problem as a user might
> use the same passed in reference (size), but that has been changed, again
> in a call to setSize, and due to the implementation of setSize
> (following), a size change is not recognized:
>
>     	if((size!=null && size.equals(offScrnSize)==false) ||
> 	   size!=offScrnSize
> 	  )
> 	{
>     		offScrnSizeChanged=true;
>                 offScrnSize=size;
> 	        initDrawable();
> 	}
>
> It seems it would be better if the components of the reference (size.width
> and size.height) are copied to offScrnSize, than by saving the reference
> itself.
>
> To all relevant folks, thanks again for the newer version of GL4Java ... a
> lot of these features are/were needed.
>
> nader
>
>
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

- -- 
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

iD8DBQE8YphkHdOA30NoFAARAjGFAJ9Z68T7XQtcC/otQGyUHALOv4AziwCgs+2a
LG6KowtJiqtFlLwKgIJGQQQ=
=cQmQ
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] Sharing display lists and texture maps

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

> I am porting my application from Magician to GL4Java, and there are some
> differences in the two APIs that I am trying to figure out.
> Specifically, I was sharing display lists and textures between two
> displays (ie, two GLDrawables) in my app. In the old API, I was able to
> create my second "GLDrawable" by passing in my first "GLDrawable" as an
> argument during creation. This linked the two OpenGL state machines and
> allowed the desired sharing.
> 
> Does anyone know the proper way to do this in GL4Java? In the
> GLDrawableFactory class, I saw that createGLAnimCanvas() was overloaded
> to take the arguments 'glName' and 'gluName', but I don't think that is
> what I am looking for, is it? We tried getting the Context from the
> first GLDrawable and setting it in the second GLDrawable, but that
> caused nothing to be rendered at all. Does anyone have some advice?

The GLDrawable APIs (largely borrowed from Magician) were added
fairly late, so there is still missing functionality like this.

The underlying mechanism should be available; GLContext can take
a "shared" GLContext in its constructor. There are some
demonstrations (all of which depend on subclassing GLCanvas) of
this functionality in the demos.

Re: [gl4java-usergroup] gleem (OpenGL Extremely Easy-to-Use Manipulators) for Java

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

> but what is even more interesting for me, is how to deploy a own demo using
> Java Webstart ?

See the documentation at
http://java.sun.com/products/javawebstart/ , in particular the
developers' documentation. Deploying an application is pretty
simple. One issue is that deploying applications which require
certain permissions (for example, the ability to load a native
library) requires code signing, and in order to do this properly
you need a certificate from Verisign, Thawte, or similar, which
can run into hundreds of dollars.

I'm looking into whether this signing can be done once for OpenGL
for Java, and whether applications using it can be unsigned. If
you have experience with this then please share with the mailing
list.

> And further on, will Webstart also download latest GL4Java version if not
> exsiting ?

Yes. Not only that, it will automatically download and install
the appropriate JRE.

[gl4java-usergroup] Sharing display lists and texture maps

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

I am porting my application from Magician to GL4Java, and there are some
differences in the two APIs that I am trying to figure out.
Specifically, I was sharing display lists and textures between two
displays (ie, two GLDrawables) in my app. In the old API, I was able to
create my second "GLDrawable" by passing in my first "GLDrawable" as an
argument during creation. This linked the two OpenGL state machines and
allowed the desired sharing.

Does anyone know the proper way to do this in GL4Java? In the
GLDrawableFactory class, I saw that createGLAnimCanvas() was overloaded
to take the arguments 'glName' and 'gluName', but I don't think that is
what I am looking for, is it? We tried getting the Context from the
first GLDrawable and setting it in the second GLDrawable, but that
caused nothing to be rendered at all. Does anyone have some advice?

-mark

[gl4java-usergroup] gleem (OpenGL Extremely Easy-to-Use Manipulators) for Java

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

http://www.media.mit.edu/~kbrussel/gleem/

gleem (OpenGL Extremely Easy-to-Use Manipulators) is a small,
self-contained library of 3D widgets which are easy to
incorporate into an arbitrary OpenGL application. The library has
been ported to the Java programming language from C++ using
Jausoft's OpenGL for Java. Cross-platform applications which
utilize these widgets can now be deployed over the web using Java
Web Start.  Online demos available.

[gl4java-usergroup] how to use java lang

[leon wu <tin...@ya...>]

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

Re: [gl4java-usergroup] GC Bug

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

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.

Pepijn Van Eeckhoudt

Kenneth B. Russell wrote:

>>I tried adding my implementations to the manual files. But, as I 
>>expected, the generated file contained .c file contained two 
>>implementations of the same mehtod. In the makefile, the manual and auto 
>>generated files get pasted together using cat which explains the double 
>>implementation.
>>I can't find anything that suggests glGetString gets a special treatment 
>>in the C2J code.
>>Any ideas?
>>
> 
> In the directory Gl4Java/C2J/mesa40-header there are several
> scripts which prepare the Mesa header files for processing with
> C2J. However, it isn't apparent to me how the .h files get
> generated (automatically or whether there is manual processing of
> e.g. gl-proto-auto.orig). Note that the prototype for glGetString
> is missing from gl-proto-auto-orig.h.
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 
> 

Re: [gl4java-usergroup] Disabling the verbose GLINFO output

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

> How do I disable the GLINFO output when an application
> starts? 
> 
> I read in changes.txt for 2.8.2.0 that I had to avoid the 
> debug flag. What does this mean? Where do I set these flags?
> Does it mean I have to recompile the gl4java DLLs that was 
> installed on my machine.

There are a few public static (bad) boolean flags in GLContext:
gljClassDebug, gljThreadDebug, gljNativeDebug. It looks like the
GLINFO messages are output when gljNativeDebug is set to true.
Your application is probably doing this somewhere during its
initialization.

Re: [gl4java-usergroup] Overlaying AWT stuff on a GL4Java canvas

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

> How can I overlay Java AWT/Swing components on top of my GL4Java canvas?
> Or am I going about it all wrong? I'd rather not use Swing, for
> backwards compatability reasons, but if I must... 

I don't know of a way to put a Component on top of a GLCanvas.
However, it is possible to put a set of AWT or Swing widgets
side-by-side one of OpenGL for Java's
components. gl4java.applet.SimpleGLApplet1 and
gl4java.applet.SimpleGLAnimApplet1 show how to do this.

Re: [gl4java-usergroup] GC Bug

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

> I tried adding my implementations to the manual files. But, as I 
> expected, the generated file contained .c file contained two 
> implementations of the same mehtod. In the makefile, the manual and auto 
> generated files get pasted together using cat which explains the double 
> implementation.
> I can't find anything that suggests glGetString gets a special treatment 
> in the C2J code.
> Any ideas?

In the directory Gl4Java/C2J/mesa40-header there are several
scripts which prepare the Mesa header files for processing with
C2J. However, it isn't apparent to me how the .h files get
generated (automatically or whether there is manual processing of
e.g. gl-proto-auto.orig). Note that the prototype for glGetString
is missing from gl-proto-auto-orig.h.

[gl4java-usergroup] Disabling the verbose GLINFO output

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

Hi,

I am new to gl4java, so please bear with me if this question
is stupid, but I have searched the manual an mailing list 
archives for an answer without success.

How do I disable the GLINFO output when an application
starts? 

I read in changes.txt for 2.8.2.0 that I had to avoid the 
debug flag. What does this mean? Where do I set these flags?
Does it mean I have to recompile the gl4java DLLs that was 
installed on my machine.

Jacob Marner

Re: [gl4java-usergroup] GC Bug

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

I tried adding my implementations to the manual files. But, as I 
expected, the generated file contained .c file contained two 
implementations of the same mehtod. In the makefile, the manual and auto 
generated files get pasted together using cat which explains the double 
implementation.
I can't find anything that suggests glGetString gets a special treatment 
in the C2J code.
Any ideas?

Pepijn Van Eeckhoudt

Kenneth B. Russell wrote:

>>I wrote a simple memory management module that keeps track of the
>>alocated arrays, so they can be released at a later point. I've tested
>>this idea with the tesselation stuff, and it works fine.
>>I've made these changes to the C files in the CNativeCode directory,
>>which isn't ideal (should be autogenerated). Could someone explain to me
>>where I can put my implementations of the
>>Java_gl4java_GLUFunc14JauJNI_gluTessVertex__* functions, so they would
>>appear in the generated c files automatically.
>>
> 
> These files are built by C2J. Sven can answer this better, but
> you're going to have to add them to something like
> C2J/gl-manualCodedImplJNI.c. The important thing is to then
> exclude them from the autogeneration process. I'm not sure
> whether simply adding the prototype to gl-manualCoded.orig.h will
> cause C2J to ignore the function; see how glGetString is handled
> in the Mesa header files and in the C2J Makefile.
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 
> 

Re: [gl4java-usergroup] Solaris 8 vs. Solaris 7

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

> I am now using the GLEventListener mechanism instead of inheriting from
> GLAnimCanvas. But my app still freezes after a few window resizes on Solaris
> 8. (BTW, it runs fine on Window NT.)

Try sending the process a SIGQUIT or pressing Ctrl-\ at the
command line to get a thread dump. If the VM is wedged really
hard this will not produce any output, but if it does, then it's
likely a Java-level deadlock which you can diagnose with the
resulting stack traces.

> I noticed that the latest GL4Java version (2.8.2.0) is released for
> "SUNOS_57_Solaris." Does anyone know if this Solaris 7 version tested on
> Solaris 8 yet? I am wondering if my resize problem is related to this OS
> issue.

Those builds were actually built on Solaris 8.

> When using GL4Java on Solaris, I consistantly get the following
> printout in the command window:
> 
> GLINFO: cannot find glXGetProcAddress* in OpenGL library libGL.so
> 
> Does anyone know if this is critical, or just a warning of a benign problem?

OpenGL for Java has fallback mechanisms, like using dlsym(),
built in, so this is probably benign. I don't remember precisely
whether I have seen this message on my own machine but it rings a
bell.

[gl4java-usergroup] GLINFO: cannot find glXGetProcAddress* in OpenGL library libGL.so

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

When using GL4Java on Solaris, I consistantly get the following printout in the
command window:

GLINFO: cannot find glXGetProcAddress* in OpenGL library libGL.so

Does anyone know if this is critical, or just a warning of a benign problem?

-mark

[gl4java-usergroup] Solaris 8 vs. Solaris 7

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

I am now using the GLEventListener mechanism instead of inheriting from
GLAnimCanvas. But my app still freezes after a few window resizes on Solaris
8. (BTW, it runs fine on Window NT.)

I noticed that the latest GL4Java version (2.8.2.0) is released for
"SUNOS_57_Solaris." Does anyone know if this Solaris 7 version tested on
Solaris 8 yet? I am wondering if my resize problem is related to this OS
issue.

-mark

Re: [gl4java-usergroup] Building a cube consisting of glutSolidCubes

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

Lars,

if i understand you correctly, you are rendering a bunch of glutSolidCubes
together to form a larger shape. and now you want to rotate that larger
shape (all the individual glutSolidCubes together) as one solid shape.

if you understand how to rotate one of the individual glutSolidCubes, then
you can use the same method to rotate the larger shape. the difference lies
in where you make your glRotate*() call. when you make a rotate call, it
modifies the current model-view matrix in OpenGL. this matrix will affect
everything you render for the remainder of the rendering frame. so, you
have to add a new glRotate call in your display method before you render
any of your glutSolidCubes. this additional rotate will apply to all the
small cubes, and it will rotate them all around the axis of rotation that
you provide in the rotate call.

if this didn't make sense, or i screwed up the explanation, then you can
see Chapter 3 in the OpenGL "Red" book for a good descriptoin.

-mark

Lars Beyer-Olsen wrote:

> First posting.
>
> I'm really new at this, so I hope this question is not to simple.
> What I want to do is to draw a wired cube consisting of glutSolidCubes,
> and rotate the cube like it was one object.
>
> This is the code for drawing the one of the six sides of the cube.
>
>  //Left-side
>  gl.glLoadIdentity();
>  gl.glTranslatef(-1.0f, 2.0f, -20.0f);
>  gl.glRotatef(90.0f, 0.0f, 0.0f, 1.0f);
>  gl.glScalef(6.0f, 0.5f, 0.6f);
>  glut.glutSolidCube(1.0f);
>
>  //Lower-side
>  gl.glLoadIdentity();
>  gl.glTranslatef(1.0f, 0.0f, -20.0f);
>  gl.glScalef(6.0f, 0.5f, 0.6f);
>  glut.glutSolidCube(1.0f);
>
>  //Right-side
>  gl.glLoadIdentity();
>  gl.glTranslatef(3.0f, 2.0f, -20.0f);
>  gl.glPushMatrix();
>  gl.glRotatef(90.0f, 0.0f, 0.0f, 1.0f);
>  gl.glScalef(6.0f, 0.5f, 0.6f);
>  glut.glutSolidCube(1.0f);
>
>  //Upper-side
> gl.glLoadIdentity();
> gl.glTranslatef(1.0f, 4.0f, -20.0f);
> gl.glScalef(6.0f, 0.5f, 0.6f);
> glut.glutSolidCube(1.0);
>
> I build the rest of the cube in the same way, just translating the
> glutSolidCubes around.
> My problem arises when i want to rotate all the glutSolidCubes as one
> object.
> I know how to rotate the glutSolidCubes as individual objects, but I
> don't get anywhere
> with that (do I ?).
>
> Anyone with a solution?
>
> Lars
>
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

[gl4java-usergroup] Overlaying AWT stuff on a GL4Java canvas

[Greg T. <gr...@gr...>]

Hello Everyone, 

How can I overlay Java AWT/Swing components on top of my GL4Java canvas?
Or am I going about it all wrong? I'd rather not use Swing, for
backwards compatability reasons, but if I must... 

I'm reasonably happy to create my own components (in OGL or with Java)
if necessary, but I would like to have something that is like Java's
drawRect3D, and to use TTF fonts for text. Any tips, links or examples
would be much appreciated! 

Regards, 

Greg Turner.

[gl4java-usergroup] Building a cube consisting of glutSolidCubes

[Lars Beyer-O. <lar...@hi...>]

First posting.

I'm really new at this, so I hope this question is not to simple.
What I want to do is to draw a wired cube consisting of glutSolidCubes,
and rotate the cube like it was one object.

This is the code for drawing the one of the six sides of the cube.

 //Left-side
 gl.glLoadIdentity();
 gl.glTranslatef(-1.0f, 2.0f, -20.0f);
 gl.glRotatef(90.0f, 0.0f, 0.0f, 1.0f);
 gl.glScalef(6.0f, 0.5f, 0.6f);
 glut.glutSolidCube(1.0f);

 //Lower-side
 gl.glLoadIdentity();
 gl.glTranslatef(1.0f, 0.0f, -20.0f);
 gl.glScalef(6.0f, 0.5f, 0.6f);
 glut.glutSolidCube(1.0f);

 //Right-side
 gl.glLoadIdentity();
 gl.glTranslatef(3.0f, 2.0f, -20.0f);
 gl.glPushMatrix();
 gl.glRotatef(90.0f, 0.0f, 0.0f, 1.0f);
 gl.glScalef(6.0f, 0.5f, 0.6f);
 glut.glutSolidCube(1.0f);

 //Upper-side
gl.glLoadIdentity();
gl.glTranslatef(1.0f, 4.0f, -20.0f);
gl.glScalef(6.0f, 0.5f, 0.6f);
glut.glutSolidCube(1.0);

I build the rest of the cube in the same way, just translating the
glutSolidCubes around.
My problem arises when i want to rotate all the glutSolidCubes as one
object.
I know how to rotate the glutSolidCubes as individual objects, but I
don't get anywhere
with that (do I ?).

Anyone with a solution?

Lars

Re: [gl4java-usergroup] Guide

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

> I have an existing app written in Magician and Java3D, and we
> are moving away from Magician for obvious reasons. I know
> OpenGL well, but I haven't found a good description of the
> GL4Java framework on their website. JavaDoc and example
> programs are fine for some things, but a short and sweet
> programmers guide is better. Magician had a nice guide that
> described proper use of the Context class, the glComponent
> class, the internal debugging pipelines, etc. Does such a guide
> exist for GL4Java?

The best guide is currently the demos/ directory in the source
base. There are a lot of demos showing various features of the
library like animation and off-screen rendering. The relatively
recent GLEventListener interface is also demonstrated there.
This is the recommended way of constructing applications at this
point since it provides a framework in which the library can
function "guaranteed correctly" with no chance of
subclassing-induced bugs.

> Also, we did a quick and dirty port in GL4Java with what we
> knew, and our application freezes on Solaris 8 when you resize
> the window that contains the GL4Java canvas (sometimes, but not
> all the time). Anyone have this trouble as well?

Try upgrading to the latest version (2.8.2). Make sure your app
uses the GLEventListener interface rather than subclassing. I've
checked this with the NVidia demo (demos/NVidia/VertexArrayRange)
as well as the JCanyon demo
( http://java.sun.com/products/jfc/tsc/articles/jcanyon/ ) and
both can handle being resized without locking up the app. (Note
I'm running on Windows; there might be an X11-specific bug.)

Re: [gl4java-usergroup] GC Bug

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

> I wrote a simple memory management module that keeps track of the
> alocated arrays, so they can be released at a later point. I've tested
> this idea with the tesselation stuff, and it works fine.
> I've made these changes to the C files in the CNativeCode directory,
> which isn't ideal (should be autogenerated). Could someone explain to me
> where I can put my implementations of the
> Java_gl4java_GLUFunc14JauJNI_gluTessVertex__* functions, so they would
> appear in the generated c files automatically.

These files are built by C2J. Sven can answer this better, but
you're going to have to add them to something like
C2J/gl-manualCodedImplJNI.c. The important thing is to then
exclude them from the autogeneration process. I'm not sure
whether simply adding the prototype to gl-manualCoded.orig.h will
cause C2J to ignore the function; see how glGetString is handled
in the Mesa header files and in the C2J Makefile.

[gl4java-usergroup] Guide

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

I have an existing app written in Magician and Java3D, and we are moving away from
Magician for obvious reasons. I know OpenGL well, but I haven't found a good description
of the GL4Java framework on their website. JavaDoc and example programs are fine for
some things, but a short and sweet programmers guide is better. Magician had a nice
guide that described proper use of the Context class, the glComponent class, the
internal debugging pipelines, etc. Does such a guide exist for GL4Java?

Also, we did a quick and dirty port in GL4Java with what we knew, and our application
freezes on Solaris 8 when you resize the window that contains the GL4Java canvas
(sometimes, but not all the time). Anyone have this trouble as well?

Re: [gl4java-usergroup] GC Bug

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

I wrote a simple memory management module that keeps track of the
alocated arrays, so they can be released at a later point. I've tested
this idea with the tesselation stuff, and it works fine.
I've made these changes to the C files in the CNativeCode directory,
which isn't ideal (should be autogenerated). Could someone explain to me
where I can put my implementations of the
Java_gl4java_GLUFunc14JauJNI_gluTessVertex__* functions, so they would
appear in the generated c files automatically.

thanks,
Pepijn Van Eeckhoudt


Kenneth B. Russell wrote:

 > Quick point: it is illegal to return from a native method when
 > you have called Get*Critical but without calling the succeeding
 > Release*Critical.
 >
 >
 >
 >>From: Pepijn Van Eeckhoudt <pep...@lu...>
 >>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) 
Gecko/20011120
 >>X-Accept-Language: en-us
 >>MIME-Version: 1.0
 >>Content-Type: text/plain; charset=us-ascii; format=flowed
 >>Content-Transfer-Encoding: 7bit
 >>X-Loop-Detect: 1
 >>Sender: gl4...@li...
 >>Errors-To: gl4...@li...
 >>X-BeenThere: gl4...@li...
 >>X-Mailman-Version: 2.0.5
 >>Precedence: bulk
 >>List-Help: 
<mailto:gl4...@li...?subject=help>
 >>List-Post: <mailto:gl4...@li...>
 >>List-Subscribe: 
<https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup>,
 >>	<mailto:gl4...@li...?subject=subscribe>
 >>List-Id: <gl4java-usergroup.lists.sourceforge.net>
 >>List-Unsubscribe: 
<https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup>,
 >>	<mailto:gl4...@li...?subject=unsubscribe>
 >>List-Archive: 
<http://www.geocrawler.com/redir-sf.php3?list=gl4java-usergroup>
 >>X-Original-Date: Thu, 10 Jan 2002 11:19:25 +0100
 >>Date: Thu, 10 Jan 2002 11:19:25 +0100
 >>
 >>That's exactly what i had in mind for the non buffer stuff.
 >>
 >>Pepijn Van Eeckhoudt
 >>
 >>Sven Goethel wrote:
 >>
 >> > -----BEGIN PGP SIGNED MESSAGE-----
 >> > Hash: SHA1
 >> >
 >> > On Wednesday 09 January 2002 11:43, Pepijn Van Eeckhoudt wrote:
 >> >
 >> >>Sorry 'bout the reply to the repy to the digest ;)
 >> >>
 >> >>I agree that NIO buffers are the way to go, but in the case of my
 >> >>application pre jdk 1.4 compatibility is required, so this should work
 >> >>correctly as well.
 >> >>
 >> >>
 >> >
 >> > ok, so for the pre 1.3 aera,
 >> > we may use the older non CriticalArray function or/and
 >> > do not release the GC lock within the native function stub ..
 >> >
 >> > later, the kinda END function can then relase the lock ..
 >> >
 >> > ok ?
 >> >
 >> > cheers, sven
 >> > -----BEGIN PGP SIGNATURE-----
 >> > Version: GnuPG v1.0.6 (GNU/Linux)
 >> > Comment: For info see http://www.gnupg.org
 >> >
 >> > iD8DBQE8PCqIHdOA30NoFAARAquxAJ47ez1soIMt9lv/HoZdmGIKEEn/OwCfXmv8
 >> > 0U9WG7fJucQ0NAWP2LQmU0E=
 >> > =VSxh
 >> > -----END PGP SIGNATURE-----
 >> >
 >> > _______________________________________________
 >> > gl4java-usergroup mailing list
 >> > gl4...@li...
 >> > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
 >> >
 >> >
 >>
 >>
 >>
 >>
 >>_______________________________________________
 >>gl4java-usergroup mailing list
 >>gl4...@li...
 >>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
 >>
 >
 > _______________________________________________
 > gl4java-usergroup mailing list
 > gl4...@li...
 > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
 >
 >