Menu
▾
▴
gl4java-usergroup
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(39) |
Feb
(22) |
Mar
(41) |
Apr
(44) |
May
(47) |
Jun
(25) |
Jul
(28) |
Aug
(39) |
Sep
(35) |
Oct
(31) |
Nov
(31) |
Dec
(3) |
| 2001 |
Jan
(18) |
Feb
(43) |
Mar
(47) |
Apr
(38) |
May
(9) |
Jun
(20) |
Jul
(8) |
Aug
(11) |
Sep
(15) |
Oct
(43) |
Nov
(27) |
Dec
(73) |
| 2002 |
Jan
(42) |
Feb
(47) |
Mar
(49) |
Apr
(58) |
May
(12) |
Jun
(68) |
Jul
(42) |
Aug
(9) |
Sep
(19) |
Oct
(36) |
Nov
(28) |
Dec
(12) |
| 2003 |
Jan
(13) |
Feb
(24) |
Mar
(40) |
Apr
(52) |
May
(39) |
Jun
(46) |
Jul
(17) |
Aug
(5) |
Sep
(4) |
Oct
(9) |
Nov
(13) |
Dec
(12) |
| 2004 |
Jan
(1) |
Feb
(17) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(6) |
Nov
(6) |
Dec
(3) |
| 2005 |
Jan
|
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
(4) |
Oct
(3) |
Nov
(3) |
Dec
(1) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
(5) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(5) |
| 2007 |
Jan
(3) |
Feb
(11) |
Mar
(5) |
Apr
(5) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(5) |
| 2008 |
Jan
(7) |
Feb
(8) |
Mar
(30) |
Apr
(17) |
May
(20) |
Jun
(8) |
Jul
(19) |
Aug
(10) |
Sep
(7) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(13) |
Feb
(7) |
Mar
(13) |
Apr
(27) |
May
(95) |
Jun
(77) |
Jul
(43) |
Aug
(25) |
Sep
(24) |
Oct
(32) |
Nov
(6) |
Dec
(6) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(30) |
Apr
(58) |
May
(60) |
Jun
(72) |
Jul
(32) |
Aug
(45) |
Sep
(19) |
Oct
(4) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-09 09:39:34
|
1. It depends on where you keep the pointer, in java or in c. If you keep a pointer in java it won't make any difference. I'm working on keeping a pointer in the c code. (or at least trying ;)) The problem lies in the way arrays are referenced in the C code. A pointer to the array is retrieved using GetPrimitiveArrayCritical, this pointer is then used for the opengl call, and then the array is released again. This means that the data the pointer refers to is not locked when the jni call returns (in my case gluTessVertex). When the java gc runs, it won't mark the data as garbage if I keep a reference to it in java, BUT this doesn't mean that the location of the data in memory will not change (see mark & sweep gc). The pointer that opengl got during the jni call however will still refer to the old memory location where there might now be random data. What is necessary to fix this is to keep a native copy of the data and use a pointer to this native copy instead of a pointer to the java object. This raises the problem of finding the right time to free the native copy. 2. This would work (I think) , but creating a display list for code that runs only once seems like unnecessary overhead. Also this is just a workaround. What I'm looking for is a way to fix the problem, so you don't need workarounds. The opengl code by itslef is correct so (imho) it should work with gl4java without workarounds. Pepijn Van Eeckhoudt pet...@ba... wrote: > > Are there not two simple solutions to this problem: > > - You could maintain a pointer to the array yourself. Then the stuff > wouldn't get GC'd in the first place. > - You could stick your call to gluTessVertex in a display list. Then the > garbage collector can let itself > loose on the array as much as it likes, cos the data will be > (effectively) server-side by then. > > Or am I missing something here? > > Pete > > > > >>-----Original Message----- >>From: gl4...@li... >>[mailto:gl4...@li...] >>Sent: Tuesday, January 08, 2002 8:10 PM >>To: gl4...@li... >>Cc: gl4...@li... >>Subject: gl4java-usergroup digest, Vol 1 #323 - 4 msgs >> >> >> *** WARNING *** >> >>This mail has originated outside your organization, >>either from an external partner or the Global Internet. >> Keep this in mind if you answer this message. >> >> >>Send gl4java-usergroup mailing list submissions to >> gl4...@li... >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup >>or, via email, send a message with subject or body 'help' to >> gl4...@li... >> >>You can reach the person managing the list at >> gl4...@li... >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of gl4java-usergroup digest..." >> >> >>Today's Topics: >> >> 1. GC Bug (Pepijn Van Eeckhoudt) >> 2. Re: GC Bug (Kenneth B. Russell) >> 3. Re: GC Bug (Pepijn Van Eeckhoudt) >> 4. Re: GC Bug (Sven Goethel) >> >>--__--__-- >> >>Message: 1 >>Date: Tue, 08 Jan 2002 16:33:33 +0100 >>From: Pepijn Van Eeckhoudt <pep...@lu...> >>To: gluser <gl4...@li...> >>Subject: [gl4java-usergroup] GC Bug >> >>While using the GLU tesselator with 700+ points, I encountered very >>peculiar behavior. Above a certain amount of points, the end >>result of >>the tesselation would be completely messed up. After reading the >>comments in the Nvidia/DirectBuffer demo about the GC bug, I >>took a look >>at the native code that handles a gluTessVertex call and >>found that no >>copy is made of the data that is passed to this function. The OpenGL >>manual states that a call to gluTessVertex only keeps a >>pointer to the >>data array and does not make a copy itself. I assume that what's >>happening in my program is that the garbage collector is >>moving around >>(and probably even freeing) some of the coordinate arrays, >>because they >>are neither pinned or copied. Is this assumption correct? If it is >>correct will this be fixed any time soon? I know that the >>problem can be >>resolved by using direct buffers, but i would like to have pre 1.4 >>compatibility. >> >>Pepijn Van Eeckhoudt >> >> >> >>--__--__-- >> >>Message: 2 >>Date: Tue, 8 Jan 2002 11:50:36 -0500 (EST) >>To: Pepijn Van Eeckhoudt <pep...@lu...> >>CC: gl4...@li... >>Subject: Re: [gl4java-usergroup] GC Bug >>From: "Kenneth B. Russell" <kbr...@al...> >>Reply-to: kbr...@al... >> >> >> >>>While using the GLU tesselator with 700+ points, I encountered very >>>peculiar behavior. Above a certain amount of points, the >>> >>end result of >> >>>the tesselation would be completely messed up. After reading the >>>comments in the Nvidia/DirectBuffer demo about the GC bug, >>> >>I took a look >> >>>at the native code that handles a gluTessVertex call and >>> >>found that no >> >>>copy is made of the data that is passed to this function. >>> >>The OpenGL >> >>>manual states that a call to gluTessVertex only keeps a >>> >>pointer to the >> >>>data array and does not make a copy itself. I assume that what's >>>happening in my program is that the garbage collector is >>> >>moving around >> >>>(and probably even freeing) some of the coordinate arrays, >>> >>because they >> >>>are neither pinned or copied. Is this assumption correct? >>> >>It's hard to tell what the GLU tesselator is doing under the hood >>from looking at its man pages. If it is holding a pointer to the >>passed GLdouble* then you could be correct. An easier way to >>determine whether this is the problem is to run with -XX:+PrintGC >>(HotSpot only) or -verbose:gc (any JVM, I think). If you see GC >>messages at the times when the vetices are corrupted then this is >>the problem. Otherwise it could be a bug in your application or >>possibly in GL4Java. >> >> >>>If it is correct will this be fixed any time soon? I know that >>>the problem can be resolved by using direct buffers, but i >>>would like to have pre 1.4 compatibility. >>> >>There is no good solution for this kind of problem on earlier >>JDKs. Alternatives include performing a data copy via JNI (which >>requires an associated free somewhere, which is sometimes hard to >>figure out when to do, or having a static data buffer, which >>requires synchronization) or performing pinning, which is >>complicated or impossible depending on the GC algorithm. >> >> >>--__--__-- >> >>Message: 3 >>Date: Tue, 08 Jan 2002 18:02:15 +0100 >>From: Pepijn Van Eeckhoudt <pep...@lu...> >>CC: gl4...@li... >>Subject: Re: [gl4java-usergroup] GC Bug >>To: gl4...@li... >> >>In the red book (1.2 third edition) on page 482 second >>paragraph, it is >>stated that only a pointer is kept inside the tesselator :). The >>tesselator kicks in when you call glTessEndPolygon. My >>suggestion would >>be to copy the data that is passed in glTessVertex calls, and >>to free it >>after glTessEndPolygon has returned. I modified my program so it uses >>direct buffers and this works fine. If I keep the exact same >>code, but >>pass a double[] it's messed up again, so the problem isn't in >>my program. >> >>Pepijn Van Eeckhoudt >> >>Kenneth B. Russell wrote: >> >> >>>>While using the GLU tesselator with 700+ points, I encountered very >>>>peculiar behavior. Above a certain amount of points, the >>>> >>end result of >> >>>>the tesselation would be completely messed up. After reading the >>>>comments in the Nvidia/DirectBuffer demo about the GC bug, >>>> >>I took a look >> >>>>at the native code that handles a gluTessVertex call and >>>> >>found that no >> >>>>copy is made of the data that is passed to this function. >>>> >>The OpenGL >> >>>>manual states that a call to gluTessVertex only keeps a >>>> >>pointer to the >> >>>>data array and does not make a copy itself. I assume that what's >>>>happening in my program is that the garbage collector is >>>> >>moving around >> >>>>(and probably even freeing) some of the coordinate arrays, >>>> >>because they >> >>>>are neither pinned or copied. Is this assumption correct? >>>> >>>> >>>It's hard to tell what the GLU tesselator is doing under the hood >>>from looking at its man pages. If it is holding a pointer to the >>>passed GLdouble* then you could be correct. An easier way to >>>determine whether this is the problem is to run with -XX:+PrintGC >>>(HotSpot only) or -verbose:gc (any JVM, I think). If you see GC >>>messages at the times when the vetices are corrupted then this is >>>the problem. Otherwise it could be a bug in your application or >>>possibly in GL4Java. >>> >>> >>> >>>>If it is correct will this be fixed any time soon? I know that >>>>the problem can be resolved by using direct buffers, but i >>>>would like to have pre 1.4 compatibility. >>>> >>>> >>>There is no good solution for this kind of problem on earlier >>>JDKs. Alternatives include performing a data copy via JNI (which >>>requires an associated free somewhere, which is sometimes hard to >>>figure out when to do, or having a static data buffer, which >>>requires synchronization) or performing pinning, which is >>>complicated or impossible depending on the GC algorithm. >>> >>> >>> >> >> >> >>--__--__-- >> >>Message: 4 >>From: Sven Goethel <sgo...@ja...> >>Organization: Jausoft - Sven Goethel Software Development >>To: Pepijn Van Eeckhoudt <pep...@lu...>, >> gl4...@li... >>Subject: Re: [gl4java-usergroup] GC Bug >>Date: Tue, 8 Jan 2002 19:55:40 +0100 >> >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>On Tuesday 08 January 2002 18:02, Pepijn Van Eeckhoudt wrote: >> >>>In the red book (1.2 third edition) on page 482 second >>> >>paragraph, it is >> >>>stated that only a pointer is kept inside the tesselator :). The >>>tesselator kicks in when you call glTessEndPolygon. My >>> >>suggestion would >> >>>be to copy the data that is passed in glTessVertex calls, >>> >>and to free it >> >>>after glTessEndPolygon has returned. I modified my program >>> >>so it uses >> >>>direct buffers and this works fine. If I keep the exact >>> >>same code, but >> >>>pass a double[] it's messed up again, so the problem isn't >>> >>in my program. >> >>>Pepijn Van Eeckhoudt >>> >>thx .. >> >>for the next future, we need to support many more NIO Buffer >>functions, true ! >> >>so you are welcome to add such NIO support to the manuall coded one, >>like you suggested e.g. for GLU functions .. >> >>you can find such manual codes within the GL4Java/C2J/manual >>directory ! >> >>then we need some new functions within the: >> gl4java/GLUFunc14.java (interface) >> C2J/manual/glu-manualCodedVirt-14.java (manual part) >> >> gl4java/GLUFunc14JauJNI.java (implementation - JNI >>declarations and stubs ..) >> C2J/manual/glu-manualCodedImplJNI1-14.java (manual part) >> >> CNativeCode/OpenGLU_JauJNI14_funcs.c (native implementation) >> C2J/manual/glu-manualCodedImplJNI14.c (manual part) >> >>just have a look - and understand, how it is done within the >>manual GLFunc14* counterpart of the NV extension ..: >> >>GL4Java/C2J/manual: >> gl-manualCodedImplJNI1-14.java >>gl-manualCodedImplJNI14.c gl-manualCodedVirt1-14.java >> >>we might want to make the memory managment functions more >>general purpose, >>so we can use them for e.g. (as you suggested) >> - glTessVertex >> - we should create a native NIO buffer which >>will be used .., >> straight outta the java application, >> or by a new general purpose GL4Java utility function .. >> >> - all passed NIO buffers might be freed by the >>glTessEndPolygon function >> or by another one .. if allocated by a GL4Java >>utility function >> >> - glTessEndPolygon >> - might free all passed NIO buffers, if >>allocated by a GL4Java utility function >> >>so this little concept - please review and make it more clean RFC .., >>might be introduced to all OpenGL functions which handles a >>big amount of data, >>e.g. textures etc., where the JVM's GC might moves or cleans >>the memory .. >> >>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 >> >>iD8DBQE8O0CsHdOA30NoFAARAkiaAJsGztRzxtMEUGAV4laLTBPGvr4ObQCghN3Z >>49ejsxPlH7Z2+x8o22MLimE= >>=08nL >>-----END PGP SIGNATURE----- >> >> >> >>--__--__-- >> >>_______________________________________________ >>gl4java-usergroup mailing list >>gl4...@li... >>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup >> >> >>End of gl4java-usergroup Digest >> >> > > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > |
|
From: <pet...@ba...> - 2002-01-09 09:06:33
|
Are there not two simple solutions to this problem: - You could maintain a pointer to the array yourself. Then the stuff wouldn't get GC'd in the first place. - You could stick your call to gluTessVertex in a display list. Then the garbage collector can let itself loose on the array as much as it likes, cos the data will be (effectively) server-side by then. Or am I missing something here? Pete > -----Original Message----- > From: gl4...@li... > [mailto:gl4...@li...] > Sent: Tuesday, January 08, 2002 8:10 PM > To: gl4...@li... > Cc: gl4...@li... > Subject: gl4java-usergroup digest, Vol 1 #323 - 4 msgs > > > *** WARNING *** > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > Send gl4java-usergroup mailing list submissions to > gl4...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > or, via email, send a message with subject or body 'help' to > gl4...@li... > > You can reach the person managing the list at > gl4...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gl4java-usergroup digest..." > > > Today's Topics: > > 1. GC Bug (Pepijn Van Eeckhoudt) > 2. Re: GC Bug (Kenneth B. Russell) > 3. Re: GC Bug (Pepijn Van Eeckhoudt) > 4. Re: GC Bug (Sven Goethel) > > --__--__-- > > Message: 1 > Date: Tue, 08 Jan 2002 16:33:33 +0100 > From: Pepijn Van Eeckhoudt <pep...@lu...> > To: gluser <gl4...@li...> > Subject: [gl4java-usergroup] GC Bug > > While using the GLU tesselator with 700+ points, I encountered very > peculiar behavior. Above a certain amount of points, the end > result of > the tesselation would be completely messed up. After reading the > comments in the Nvidia/DirectBuffer demo about the GC bug, I > took a look > at the native code that handles a gluTessVertex call and > found that no > copy is made of the data that is passed to this function. The OpenGL > manual states that a call to gluTessVertex only keeps a > pointer to the > data array and does not make a copy itself. I assume that what's > happening in my program is that the garbage collector is > moving around > (and probably even freeing) some of the coordinate arrays, > because they > are neither pinned or copied. Is this assumption correct? If it is > correct will this be fixed any time soon? I know that the > problem can be > resolved by using direct buffers, but i would like to have pre 1.4 > compatibility. > > Pepijn Van Eeckhoudt > > > > --__--__-- > > Message: 2 > Date: Tue, 8 Jan 2002 11:50:36 -0500 (EST) > To: Pepijn Van Eeckhoudt <pep...@lu...> > CC: gl4...@li... > Subject: Re: [gl4java-usergroup] GC Bug > From: "Kenneth B. Russell" <kbr...@al...> > Reply-to: kbr...@al... > > > > While using the GLU tesselator with 700+ points, I encountered very > > peculiar behavior. Above a certain amount of points, the > end result of > > the tesselation would be completely messed up. After reading the > > comments in the Nvidia/DirectBuffer demo about the GC bug, > I took a look > > at the native code that handles a gluTessVertex call and > found that no > > copy is made of the data that is passed to this function. > The OpenGL > > manual states that a call to gluTessVertex only keeps a > pointer to the > > data array and does not make a copy itself. I assume that what's > > happening in my program is that the garbage collector is > moving around > > (and probably even freeing) some of the coordinate arrays, > because they > > are neither pinned or copied. Is this assumption correct? > > It's hard to tell what the GLU tesselator is doing under the hood > from looking at its man pages. If it is holding a pointer to the > passed GLdouble* then you could be correct. An easier way to > determine whether this is the problem is to run with -XX:+PrintGC > (HotSpot only) or -verbose:gc (any JVM, I think). If you see GC > messages at the times when the vetices are corrupted then this is > the problem. Otherwise it could be a bug in your application or > possibly in GL4Java. > > > If it is correct will this be fixed any time soon? I know that > > the problem can be resolved by using direct buffers, but i > > would like to have pre 1.4 compatibility. > > There is no good solution for this kind of problem on earlier > JDKs. Alternatives include performing a data copy via JNI (which > requires an associated free somewhere, which is sometimes hard to > figure out when to do, or having a static data buffer, which > requires synchronization) or performing pinning, which is > complicated or impossible depending on the GC algorithm. > > > --__--__-- > > Message: 3 > Date: Tue, 08 Jan 2002 18:02:15 +0100 > From: Pepijn Van Eeckhoudt <pep...@lu...> > CC: gl4...@li... > Subject: Re: [gl4java-usergroup] GC Bug > To: gl4...@li... > > In the red book (1.2 third edition) on page 482 second > paragraph, it is > stated that only a pointer is kept inside the tesselator :). The > tesselator kicks in when you call glTessEndPolygon. My > suggestion would > be to copy the data that is passed in glTessVertex calls, and > to free it > after glTessEndPolygon has returned. I modified my program so it uses > direct buffers and this works fine. If I keep the exact same > code, but > pass a double[] it's messed up again, so the problem isn't in > my program. > > Pepijn Van Eeckhoudt > > Kenneth B. Russell wrote: > > >>While using the GLU tesselator with 700+ points, I encountered very > >>peculiar behavior. Above a certain amount of points, the > end result of > >>the tesselation would be completely messed up. After reading the > >>comments in the Nvidia/DirectBuffer demo about the GC bug, > I took a look > >>at the native code that handles a gluTessVertex call and > found that no > >>copy is made of the data that is passed to this function. > The OpenGL > >>manual states that a call to gluTessVertex only keeps a > pointer to the > >>data array and does not make a copy itself. I assume that what's > >>happening in my program is that the garbage collector is > moving around > >>(and probably even freeing) some of the coordinate arrays, > because they > >>are neither pinned or copied. Is this assumption correct? > >> > > > > It's hard to tell what the GLU tesselator is doing under the hood > > from looking at its man pages. If it is holding a pointer to the > > passed GLdouble* then you could be correct. An easier way to > > determine whether this is the problem is to run with -XX:+PrintGC > > (HotSpot only) or -verbose:gc (any JVM, I think). If you see GC > > messages at the times when the vetices are corrupted then this is > > the problem. Otherwise it could be a bug in your application or > > possibly in GL4Java. > > > > > >>If it is correct will this be fixed any time soon? I know that > >>the problem can be resolved by using direct buffers, but i > >>would like to have pre 1.4 compatibility. > >> > > > > There is no good solution for this kind of problem on earlier > > JDKs. Alternatives include performing a data copy via JNI (which > > requires an associated free somewhere, which is sometimes hard to > > figure out when to do, or having a static data buffer, which > > requires synchronization) or performing pinning, which is > > complicated or impossible depending on the GC algorithm. > > > > > > > > > --__--__-- > > Message: 4 > From: Sven Goethel <sgo...@ja...> > Organization: Jausoft - Sven Goethel Software Development > To: Pepijn Van Eeckhoudt <pep...@lu...>, > gl4...@li... > Subject: Re: [gl4java-usergroup] GC Bug > Date: Tue, 8 Jan 2002 19:55:40 +0100 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 08 January 2002 18:02, Pepijn Van Eeckhoudt wrote: > > In the red book (1.2 third edition) on page 482 second > paragraph, it is > > stated that only a pointer is kept inside the tesselator :). The > > tesselator kicks in when you call glTessEndPolygon. My > suggestion would > > be to copy the data that is passed in glTessVertex calls, > and to free it > > after glTessEndPolygon has returned. I modified my program > so it uses > > direct buffers and this works fine. If I keep the exact > same code, but > > pass a double[] it's messed up again, so the problem isn't > in my program. > > > > Pepijn Van Eeckhoudt > > thx .. > > for the next future, we need to support many more NIO Buffer > functions, true ! > > so you are welcome to add such NIO support to the manuall coded one, > like you suggested e.g. for GLU functions .. > > you can find such manual codes within the GL4Java/C2J/manual > directory ! > > then we need some new functions within the: > gl4java/GLUFunc14.java (interface) > C2J/manual/glu-manualCodedVirt-14.java (manual part) > > gl4java/GLUFunc14JauJNI.java (implementation - JNI > declarations and stubs ..) > C2J/manual/glu-manualCodedImplJNI1-14.java (manual part) > > CNativeCode/OpenGLU_JauJNI14_funcs.c (native implementation) > C2J/manual/glu-manualCodedImplJNI14.c (manual part) > > just have a look - and understand, how it is done within the > manual GLFunc14* counterpart of the NV extension ..: > > GL4Java/C2J/manual: > gl-manualCodedImplJNI1-14.java > gl-manualCodedImplJNI14.c gl-manualCodedVirt1-14.java > > we might want to make the memory managment functions more > general purpose, > so we can use them for e.g. (as you suggested) > - glTessVertex > - we should create a native NIO buffer which > will be used .., > straight outta the java application, > or by a new general purpose GL4Java utility function .. > > - all passed NIO buffers might be freed by the > glTessEndPolygon function > or by another one .. if allocated by a GL4Java > utility function > > - glTessEndPolygon > - might free all passed NIO buffers, if > allocated by a GL4Java utility function > > so this little concept - please review and make it more clean RFC .., > might be introduced to all OpenGL functions which handles a > big amount of data, > e.g. textures etc., where the JVM's GC might moves or cleans > the memory .. > > 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 > > iD8DBQE8O0CsHdOA30NoFAARAkiaAJsGztRzxtMEUGAV4laLTBPGvr4ObQCghN3Z > 49ejsxPlH7Z2+x8o22MLimE= > =08nL > -----END PGP SIGNATURE----- > > > > --__--__-- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > > End of gl4java-usergroup Digest > ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** |
|
From: Sven G. <sgo...@ja...> - 2002-01-09 05:23:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 28 December 2001 14:42, Lamy Jean-Baptiste wrote: > Hi every one ! > Hi Lamy. > I'm packaging my famous ;-) game Arkanae in RPM, and GL4Java by the same > way ! cool .. > > The packaged version is 2.8.2.0 for Mandrake Linux; it should work for > other RPM-based distribution ! interesting .. > > Sven, here is the SPEC file for GL4Java and a patch. i do not know the RPM spec files .. should learn how to read it ;-) > To build the RPM, you just need those files and the source tarball (renamed > and recompressed for convennience GL4Java-2.8.2.0.tar.bz2). > The spec file says some info (you may want to check them) and the way to > compile the source (=make x11). > The patch include the file symbol.mak and a small modification to the file > CNativeCode/glu-disp-var.h (it seems that GLUnurbs is not defined with some > version of Mesa). you need an opengl 1.3 (at least opengl 1.2) compliant opengl header file, e.g. mesa 4.0, or the latest XFree86 4.1.0 + DRI one .. (do not use NVidia's .. i remember some problems this those .., but try it) so those changes for earlier opengl header files are not usefull to compile .. if we want to ease the build process, i strongly recommend, that somebody does create an gnu (auto)configuration system ... just adding an "make x11" within an SRPM is IMHO not enough .. but a binary RPM may be cool beneath our installer, to offer binaries to linux distributions .. > > Greeting everyone ! > > Jiba thanxs a lot for your efforts .. 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 iD8DBQE8O9OyHdOA30NoFAARAr3VAKCSggc9hM2GuyDqHOeDf35Jt8v35wCeN+lk HziwfbHx7FSl7HaLpIQ1fLE= =12xD -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2002-01-09 05:10:39
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 31 December 2001 12:00, Marcel Romijn wrote:
> Hello,
>
> I've been looking at the GL4Java implementation to use OpenGL in Java.
>
> To learn it, I've ported the NeHe lesson 1 through 8 in Java.
did you port other lessons than allready ported ?
if so, please mail the sources (zip, bzip2) - thx
> This all
> works nice, but I noticed that drawing gets slower as my window size
> increases. So I printed out 'gl.glGetString( gl.GL_RENDERER )' and
> 'gl.glGetString( gl.GL_VENDOR )'. They return "GDI Generic" and "Microsoft
> Corporation" respectively. This means that the software rendering of
> Windows is used.
do a "java gl4java.GLContext -info"
RTFM -> read the FAQ ;-)
>
> When I run the NeHe lessons, compiled in C++, they all run very fast,
> independent of the window size (when running windowed and not full-screen).
> So no problem with the hardware acceleration.
>
> Is there a reason why GL4Java end up with the software rendering?
i do not know ..
GL4Java does load the opengl32.dll (i guess thats the name ;-),
within the default location.
so, if you do have installed an opengl ICD, e.g. nvidia's detonator etc.,
it is hw accelerated automatically, and you should see the vendors id ..
but - if you have linked an alternated GL dll to your c++ nehe lessons,
you need to tell GL4Java which one you need ..
have a look at CHANGES.txt:
<snip>
5th April 2001 (Version 2.7.0 - Release 0 )
<snip>
o It is now possible to specify/switch the gl/glu lib's at runtime !!
E.g. the classes
"gl4java.GLContext",
"gl4java.utils.Test"
(you better use the one within the demos/MiscDemos
directory just called Test)
now takes the arguments:
"-GLLib <name>" and
"-GLULib <name>"
to specify the OpenGL and GLU library which should be used !!
You can also switch to another GL/GLU set of libraries,
while just calling gl4java.GLContext.gljFetchGLFunctions(...),
with force:=true !
But be shure that no GLContext is alive ;-)
Last but not least, you can use gltool's feature of
specifying the GL/GLU library names by the systems
environment variables:
GLTOOL_USE_GLLIB - OpenGL library name
GLTOOL_USE_GLULIB - GLU library name
these environment variables does _always_ overrides
any given ones from the java side !
<snip>
just give the later solution a try, if you do not use an ICD ..,
or install your non-ICD opengl dll (with the name opengl32.dll)
to your:
- current directory, or
- to the default system[32] directory ..
but be sure, the opengl32.dll you want to use should/must contain
at least the std. opengl 1.1 function set, otherwise it is very useless.
remind: all opengl function (-pointers) are fetched automagically
from the opengl dll.
if any function is not implemented within the dll,
the application will _not_ crash, just nothing happens then !
>
> Thanks in advance,
> Marcel Romijn
I hope this helps, because this is for general purpose,
I fwd'ed this Q to the mailinglist - later we will add it to the FAQ !!
please use the mailinglist for further questions !
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
iD8DBQE8O9DDHdOA30NoFAARAuGKAKC/N1YcsJwojh14NADOm36Ic9VJFACfTjQ3
uD3VtvEZ/kerYLpbY8UzU7I=
=6049
-----END PGP SIGNATURE-----
|
|
From: Sven G. <sgo...@ja...> - 2002-01-08 18:56:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 08 January 2002 18:02, Pepijn Van Eeckhoudt wrote: > In the red book (1.2 third edition) on page 482 second paragraph, it is > stated that only a pointer is kept inside the tesselator :). The > tesselator kicks in when you call glTessEndPolygon. My suggestion would > be to copy the data that is passed in glTessVertex calls, and to free it > after glTessEndPolygon has returned. I modified my program so it uses > direct buffers and this works fine. If I keep the exact same code, but > pass a double[] it's messed up again, so the problem isn't in my program. > > Pepijn Van Eeckhoudt thx .. for the next future, we need to support many more NIO Buffer functions, true ! so you are welcome to add such NIO support to the manuall coded one, like you suggested e.g. for GLU functions .. you can find such manual codes within the GL4Java/C2J/manual directory ! then we need some new functions within the: gl4java/GLUFunc14.java (interface) C2J/manual/glu-manualCodedVirt-14.java (manual part) gl4java/GLUFunc14JauJNI.java (implementation - JNI declarations and stubs ..) C2J/manual/glu-manualCodedImplJNI1-14.java (manual part) CNativeCode/OpenGLU_JauJNI14_funcs.c (native implementation) C2J/manual/glu-manualCodedImplJNI14.c (manual part) just have a look - and understand, how it is done within the manual GLFunc14* counterpart of the NV extension ..: GL4Java/C2J/manual: gl-manualCodedImplJNI1-14.java gl-manualCodedImplJNI14.c gl-manualCodedVirt1-14.java we might want to make the memory managment functions more general purpose, so we can use them for e.g. (as you suggested) - glTessVertex - we should create a native NIO buffer which will be used .., straight outta the java application, or by a new general purpose GL4Java utility function .. - all passed NIO buffers might be freed by the glTessEndPolygon function or by another one .. if allocated by a GL4Java utility function - glTessEndPolygon - might free all passed NIO buffers, if allocated by a GL4Java utility function so this little concept - please review and make it more clean RFC .., might be introduced to all OpenGL functions which handles a big amount of data, e.g. textures etc., where the JVM's GC might moves or cleans the memory .. 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 iD8DBQE8O0CsHdOA30NoFAARAkiaAJsGztRzxtMEUGAV4laLTBPGvr4ObQCghN3Z 49ejsxPlH7Z2+x8o22MLimE= =08nL -----END PGP SIGNATURE----- |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-08 17:02:25
|
In the red book (1.2 third edition) on page 482 second paragraph, it is stated that only a pointer is kept inside the tesselator :). The tesselator kicks in when you call glTessEndPolygon. My suggestion would be to copy the data that is passed in glTessVertex calls, and to free it after glTessEndPolygon has returned. I modified my program so it uses direct buffers and this works fine. If I keep the exact same code, but pass a double[] it's messed up again, so the problem isn't in my program. Pepijn Van Eeckhoudt Kenneth B. Russell wrote: >>While using the GLU tesselator with 700+ points, I encountered very >>peculiar behavior. Above a certain amount of points, the end result of >>the tesselation would be completely messed up. After reading the >>comments in the Nvidia/DirectBuffer demo about the GC bug, I took a look >>at the native code that handles a gluTessVertex call and found that no >>copy is made of the data that is passed to this function. The OpenGL >>manual states that a call to gluTessVertex only keeps a pointer to the >>data array and does not make a copy itself. I assume that what's >>happening in my program is that the garbage collector is moving around >>(and probably even freeing) some of the coordinate arrays, because they >>are neither pinned or copied. Is this assumption correct? >> > > It's hard to tell what the GLU tesselator is doing under the hood > from looking at its man pages. If it is holding a pointer to the > passed GLdouble* then you could be correct. An easier way to > determine whether this is the problem is to run with -XX:+PrintGC > (HotSpot only) or -verbose:gc (any JVM, I think). If you see GC > messages at the times when the vetices are corrupted then this is > the problem. Otherwise it could be a bug in your application or > possibly in GL4Java. > > >>If it is correct will this be fixed any time soon? I know that >>the problem can be resolved by using direct buffers, but i >>would like to have pre 1.4 compatibility. >> > > There is no good solution for this kind of problem on earlier > JDKs. Alternatives include performing a data copy via JNI (which > requires an associated free somewhere, which is sometimes hard to > figure out when to do, or having a static data buffer, which > requires synchronization) or performing pinning, which is > complicated or impossible depending on the GC algorithm. > > |
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-08 16:50:43
|
> While using the GLU tesselator with 700+ points, I encountered very > peculiar behavior. Above a certain amount of points, the end result of > the tesselation would be completely messed up. After reading the > comments in the Nvidia/DirectBuffer demo about the GC bug, I took a look > at the native code that handles a gluTessVertex call and found that no > copy is made of the data that is passed to this function. The OpenGL > manual states that a call to gluTessVertex only keeps a pointer to the > data array and does not make a copy itself. I assume that what's > happening in my program is that the garbage collector is moving around > (and probably even freeing) some of the coordinate arrays, because they > are neither pinned or copied. Is this assumption correct? It's hard to tell what the GLU tesselator is doing under the hood from looking at its man pages. If it is holding a pointer to the passed GLdouble* then you could be correct. An easier way to determine whether this is the problem is to run with -XX:+PrintGC (HotSpot only) or -verbose:gc (any JVM, I think). If you see GC messages at the times when the vetices are corrupted then this is the problem. Otherwise it could be a bug in your application or possibly in GL4Java. > If it is correct will this be fixed any time soon? I know that > the problem can be resolved by using direct buffers, but i > would like to have pre 1.4 compatibility. There is no good solution for this kind of problem on earlier JDKs. Alternatives include performing a data copy via JNI (which requires an associated free somewhere, which is sometimes hard to figure out when to do, or having a static data buffer, which requires synchronization) or performing pinning, which is complicated or impossible depending on the GC algorithm. |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-08 15:33:42
|
While using the GLU tesselator with 700+ points, I encountered very peculiar behavior. Above a certain amount of points, the end result of the tesselation would be completely messed up. After reading the comments in the Nvidia/DirectBuffer demo about the GC bug, I took a look at the native code that handles a gluTessVertex call and found that no copy is made of the data that is passed to this function. The OpenGL manual states that a call to gluTessVertex only keeps a pointer to the data array and does not make a copy itself. I assume that what's happening in my program is that the garbage collector is moving around (and probably even freeing) some of the coordinate arrays, because they are neither pinned or copied. Is this assumption correct? If it is correct will this be fixed any time soon? I know that the problem can be resolved by using direct buffers, but i would like to have pre 1.4 compatibility. Pepijn Van Eeckhoudt |
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-03 09:20:52
|
> I found a strange problem with gl4java. I use this function call to load the > native libraries: > > GLContext.doLoadNativeLibraries (null, null, null); > > It seems like before executing this, I must do something, no matter what it > is, that has to do with AWT. At least that's how it looks. I only did two > tests (I know that's not very much), but these things should not have > anything to do with gl4java: The window system interface is pretty touchy. It's probably indirectly requiring that the AWT toolkit be initialized. This is one part of GL4Java that one just wants to get working and forget about afterward. Please feel free to dive in to the code and make cleanups. Otherwise, your best bet is probably to use a GLAnimCanvas along with a GLEventListener. |
|
From: Lamy Jean-B. <a1...@So...> - 2001-12-28 14:01:21
|
Hi every one ! I'm packaging my famous ;-) game Arkanae in RPM, and GL4Java by the same way ! The packaged version is 2.8.2.0 for Mandrake Linux; it should work for other RPM-based distribution ! Sven, here is the SPEC file for GL4Java and a patch. To build the RPM, you just need those files and the source tarball (renamed and recompressed for convennience GL4Java-2.8.2.0.tar.bz2). The spec file says some info (you may want to check them) and the way to compile the source (=make x11). The patch include the file symbol.mak and a small modification to the file CNativeCode/glu-disp-var.h (it seems that GLUnurbs is not defined with some version of Mesa). Greeting everyone ! Jiba |
|
From: Martin G. <mg...@gm...> - 2001-12-24 11:50:01
|
Hi, I found a strange problem with gl4java. I use this function call to load the native libraries: GLContext.doLoadNativeLibraries (null, null, null); It seems like before executing this, I must do something, no matter what it is, that has to do with AWT. At least that's how it looks. I only did two tests (I know that's not very much), but these things should not have anything to do with gl4java: - it worked if I create and forget an AWT frame with the line "new Frame();" - it worked if I call an empty(!) static function of a subclass of the 'Applet' class Otherwise, gl4java prints the following error message several times: GL4Java ERROR: openOpen could not lock JAWT reference! could not open a GL widget -- GL CONTEXT can't create a GL context Any idea what could be wrong? - Martin Geisse |
|
From: Sven G. <sgo...@ja...> - 2001-12-20 23:05:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 December 2001 17:22, Martin Geisse wrote: > Hi, > > I want to write a typical animation app, i.e. the graphics should > re-rendered 'all the time' (20+ times per second). Is it then possible to > ignore AWT redraw events and redraw the graphics not in the display() > method which is called by the AWT thread, but instead redraw them from the > main thread? > > It looked to me like GLAnimCanvas does exactly this internally, but I was > not sure. You can be sure, GLAnimCanvas is the best thing you can use today ;-) Have a look at the demo "gears.java" no more to explain .. > Anyway, if this is possible, should I use a GLCanvas or > GLAnimCanvas for it? Or would I duplicate most of GL*Canvas by that and had > better set up everything manually? nope, see above, look at the demo gears.java ! > > BTW, nice work! thx sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Im6zHdOA30NoFAARAoZVAKCUPtjongwRTUxhsCUqdBPq2YC7RACeJwDV qnrRcxwNCUliEfKFsrme5IQ= =MEgh -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-12-20 23:03:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 18 December 2001 23:22, Aaron Lee wrote: > Dear Sven, > > After a long arduous download and installation I finally got java > 1.3.1_01 installed, unfortunately it still leaks memory. > I am attaching the GLContext for your info. Thanks a lot! > > -Aaron dear aaron, may be your company needs more bandwith ;-) anyway, i have re-testet it ! (I will check your attachment later ..) first things first: i could not reproduce the memory leak ! My System: WinNT 4.0, 4.00.1381 Quadro2 MXR/EX NVidia OpenGL 4.00.1381.2311 523 636 kByte Ram Java 1.3.1_01 Memory meassured with the TASKMANAGER ! Test1: "java gl4java.GLContext -infotxt" 4 Runs 1.) 165552 2.) 165556 3.) 165556 4.) 165556 Test2: "appletviewer glOlympicCvsApplet.html" 2 Clicks After Animations Stops, and 3 just before 1.)165564 2.)195368 3.)195376 4.)195372 5.)195372 Well, looks like no memory leak at all .. hmm.. May be some of your drivers are broken ? I do not know ! Any more tests by other users (please include then all test, also the one of my last memory leak test results-postings). cheers, sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Im4SHdOA30NoFAARAmHaAKC6KKJTiTLQjLpJjM96e2jgFqwuTACbBZBH PcuPoxG6JC+MTMZ1X6YjZPw= =OmyX -----END PGP SIGNATURE----- |
|
From: Martin G. <mg...@gm...> - 2001-12-20 16:21:44
|
Hi, I want to write a typical animation app, i.e. the graphics should re-rendered 'all the time' (20+ times per second). Is it then possible to ignore AWT redraw events and redraw the graphics not in the display() method which is called by the AWT thread, but instead redraw them from the main thread? It looked to me like GLAnimCanvas does exactly this internally, but I was not sure. Anyway, if this is possible, should I use a GLCanvas or GLAnimCanvas for it? Or would I duplicate most of GL*Canvas by that and had better set up everything manually? BTW, nice work! --- Martin Geisse |
|
From: Aaron L. <Aar...@rt...> - 2001-12-18 22:24:01
|
Dear Sven, After a long arduous download and installation I finally got java 1.3.1_01 installed, unfortunately it still leaks memory. I am attaching the GLContext for your info. Thanks a lot! -Aaron Sven Goethel wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >dear aaron, > >i have to go in about 20 minutes .. > >hopefully, you was able to redo the tests with >the tools and facts i recommended .. > >then i hopefully can validate them on my nt machine at work .. > >i hope also, that i did not make you upset . > >please recheck your files you send to the mailinglist, >'cause the readers may get upset ;-)) > >very much thx in advance > >later, 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 > >iD8DBQE8HsXwHdOA30NoFAARApgAAJ4jYsRvmqZV3gt2TfpXDEpGgoXHPQCdEZuO >1Gor612PM5AaA7f6XSx/KZs= >=xfk1 >-----END PGP SIGNATURE----- > |
|
From: Kenneth B. R. <kbr...@al...> - 2001-12-18 15:59:34
|
> but when I read depth value, it's says me that's 16. > The aplication works well, no error, but with the same problem. > AddRemove implements GLEventListener Your card probably doesn't support that bit depth. If you're running X11, xdpyinfo can print the set of supported visuals; not sure whether there is a similar program for Windows. In my experience, it is usually possible to move the near clipping plane out far enough to avoid z-fighting. There are a lot of articles on this topic; one is http://www.opengl.org/developers/faqs/technical/depthbuffer.htm |
|
From: Ricardo <rio...@ya...> - 2001-12-18 09:20:37
|
-----Mensaje original-----
De: gl4...@li...
[mailto:gl4...@li...]En nombre de
Kenneth B. Russell
Enviado el: lunes, 17 de diciembre de 2001 16:57
Para: Ricardo
CC: gl4...@li...
Asunto: Re: [gl4java-usergroup] DEPTH BUFFER
> I have a class that extends GLCanvas, and I have the functions related
with
> tha canvas,
> preinit, init, display, ...
>
> With GLDrawableFactory I can create a GLCanvas, but how can I use the
> functions of my class,
> that extends GLCanvas, there are any examples of use?
You put that functionality into a class implementing
GLEventListener instead and set the GLEventListener of the
GLDrawable. See demos/new-style.txt and
demos/MiscDemos/gears.java for an example.
I have used:
Dimension d = getSize();
GLCapabilities caps = new GLCapabilities();
caps.setStereo(false);
caps.setDoubleBuffered(true);
caps.setDepthBits(32);
canvas =
GLDrawableFactory.getFactory().createGLAnimCanvas(caps, d.width,
d.height);
cnv = new AddRemove(canvas);
canvas.addGLEventListener(cnv);
but when I read depth value, it's says me that's 16.
The aplication works well, no error, but with the same problem.
AddRemove implements GLEventListener
_______________________________________________
gl4java-usergroup mailing list
gl4...@li...
https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
|
From: Sven G. <sgo...@ja...> - 2001-12-18 04:00:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 18 December 2001 03:55, Aaron Lee wrote: > Hi , > > I am reporting a bug regarding memory leak on Win NT 4.0 SP 6 using > jdk1.3.1, here's the problem > > here's the output when I run GLContext -infotxt: (It coredumps at the > end for exception error) > I am using NVIDIA GeForce3 Latest device driver from their website. > By the way my visualization app works fine except the leak. Thanks! > > GLContext.doLoadNativeLibraries will do it ! > jvm vendor: Sun Microsystems Inc. > jvm version: 1.3.0_02 > jvm version (parsed): major: 1, minor: 3 dear aaron, please please: - use jdk 1.3.1_01 and/or jdk 1.4.0b3 from SUN - retest it with the above versions, also with the test "java gl4java.GLContext -infotxt" - send the test result to this list, as compared with my former memory leaks .. - send us one output with the jdk 1.3.1_01 in zip compressed form thanxs a lot in advance 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 iD8DBQE8Hrg+HdOA30NoFAARAp74AJ0cDL81ac0k1lqLVVOkeIdKsIDDyACgk368 Iq+5Pn5/1QsQu1+n/9mEoq8= =Umd7 -----END PGP SIGNATURE----- |
|
From: Aaron L. <Aar...@rt...> - 2001-12-18 03:22:47
|
|
From: Aaron L. <Aar...@rt...> - 2001-12-18 03:19:28
|
Hi, I now use the jre\bin\java.exe instead of the jbuilder5 one and the report runs smoothly without any core dump. unfortunately it still leaks :-( -Aaron |
|
From: Aaron L. <Aar...@rt...> - 2001-12-18 03:00:14
|
Btw here's the result when I run it using 2.5.2
jvm vendor: Sun Microsystems Inc.
jvm version: 1.3.0_02
jvm version (parsed): major: 1, minor: 3
loaded native library: GL4JavaJauGljJNI12
loaded native library: GL4JavaJauGLJNI12
loaded native library: GL4JavaJauGLUJNI12
native Libraries loaded succesfull
GLFunc implementation GLFuncJauJNI created succesfull
GLUFunc implementation GLUFuncJauJNI created succesfull
>>> createGLContext
>>> gljInit
>>> GLContext() succeded
GL4Java - LGPL-Version
-------------------------------------------------
-------------------------------------------------
Java-Class : GL4Java.GLContext
: Version: 2.5.0.0
Vendor : Jausoft - Sven Goethel Software Development
Native-Library : GL4Java.GLContext
Version: 2.5.0.0
Vendor : Jausoft - Sven Goethel Software Development
-------------------------------------------------
Java-Class : GL4Java.GLFunc impl.
: Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
Native-Library : GL4Java.GLFunc impl.
Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
-------------------------------------------------
Java-Class : GL4Java.GLUFunc impl.
: Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
Native-Library : GL4Java.GLUFunc impl.
Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
-------------------------------------------------
OpenGL - Versions
-----------------------------------------------
GL VENDOR: NVIDIA Corporation
GL RENDERER: GeForce3/AGP/SSE
GL VERSION: 1.3.0
GL EXTENSIONS: GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture
GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_ARB_texture_cube_map GL_ARB_texture_env_add
GL_ARB_texture_env_combine GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix GL_S3_s3tc GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array GL_EXT_draw_range_elements GL_EXT_fog_coord
GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters
GL_EXT_rescale_normal GL_EXT_secondary_color
GL_EXT_separate_specular_color GL_EXT_shared_texture_palette
GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc
GL_EXT_texture_edge_clamp GL_EXT_texture_env_add
GL_EXT_texture_env_combine GL_EXT_texture_env_dot3
GL_EXT_texture_cube_map GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_object
GL_EXT_vertex_array GL_EXT_vertex_weighting
GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square
GL_NV_copy_depth_to_color GL_NV_evaluators GL_NV_fence
GL_NV_fog_distance GL_NV_light_max_exponent
GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil
GL_NV_register_combiners GL_NV_register_combiners2
GL_NV_texgen_reflection GL_NV_texture_compression_vtc
GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_texture_shader
GL_NV_texture_shader2 GL_NV_vertex_array_range GL_NV_vertex_array_range2
GL_NV_vertex_program GL_SGIS_generate_mipmap GL_SGIS_multitexture
GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow
GL_WIN_swap_hint WGL_EXT_swap_control
GLU VERSION: 1.2.2.0 Microsoft Corporation
GLU EXTENSIONS: GL_EXT_bgra
OpenGL - Function Test (438 Functions)
-----------------------------------------------
HGLRC (glContext) created: 65536
glClearIndex (2): loaded !
glClearColor (2): loaded !
glClear (2): loaded !
glIndexMask (2): loaded !
glColorMask (2): loaded !
glAlphaFunc (2): loaded !
glBlendFunc (2): loaded !
glLogicOp (2): loaded !
glCullFace (2): loaded !
glFrontFace (2): loaded !
glPointSize (2): loaded !
glLineWidth (2): loaded !
glLineStipple (2): loaded !
glPolygonMode (2): loaded !
glPolygonOffset (1): loaded !
glPolygonStipple (2): loaded !
glGetPolygonStipple (2): loaded !
glEdgeFlag (2): loaded !
glEdgeFlagv (2): loaded !
glScissor (2): loaded !
glClipPlane (2): loaded !
glGetClipPlane (2): loaded !
glDrawBuffer (2): loaded !
glReadBuffer (2): loaded !
glEnable (2): loaded !
glDisable (2): loaded !
glIsEnabled (2): loaded !
glEnableClientState (1): loaded !
glDisableClientState (1): loaded !
glGetBooleanv (2): loaded !
glGetDoublev (2): loaded !
glGetFloatv (2): loaded !
glGetIntegerv (2): loaded !
glPushAttrib (2): loaded !
glPopAttrib (2): loaded !
glPushClientAttrib (1): loaded !
glPopClientAttrib (1): loaded !
glRenderMode (2): loaded !
glGetError (2): loaded !
glFinish (2): loaded !
glFlush (2): loaded !
glHint (2): loaded !
glClearDepth (2): loaded !
glDepthFunc (2): loaded !
glDepthMask (2): loaded !
glDepthRange (2): loaded !
glClearAccum (2): loaded !
glAccum (2): loaded !
glMatrixMode (2): loaded !
glOrtho (2): loaded !
glFrustum (2): loaded !
glViewport (2): loaded !
glPushMatrix (2): loaded !
glPopMatrix (2): loaded !
glLoadIdentity (2): loaded !
glLoadMatrixd (2): loaded !
glLoadMatrixf (2): loaded !
glMultMatrixd (2): loaded !
glMultMatrixf (2): loaded !
glRotated (2): loaded !
glRotatef (2): loaded !
glScaled (2): loaded !
glScalef (2): loaded !
glTranslated (2): loaded !
glTranslatef (2): loaded !
glIsList (2): loaded !
glDeleteLists (2): loaded !
glGenLists (2): loaded !
glNewList (2): loaded !
glEndList (2): loaded !
glCallList (2): loaded !
glCallLists (2): loaded !
glListBase (2): loaded !
glBegin (2): loaded !
glEnd (2): loaded !
glVertex2d (2): loaded !
glVertex2f (2): loaded !
glVertex2i (2): loaded !
glVertex2s (2): loaded !
glVertex3d (2): loaded !
glVertex3f (2): loaded !
glVertex3i (2): loaded !
glVertex3s (2): loaded !
glVertex4d (2): loaded !
glVertex4f (2): loaded !
glVertex4i (2): loaded !
glVertex4s (2): loaded !
glVertex2dv (2): loaded !
glVertex2fv (2): loaded !
glVertex2iv (2): loaded !
glVertex2sv (2): loaded !
glVertex3dv (2): loaded !
glVertex3fv (2): loaded !
glVertex3iv (2): loaded !
glVertex3sv (2): loaded !
glVertex4dv (2): loaded !
glVertex4fv (2): loaded !
glVertex4iv (2): loaded !
glVertex4sv (2): loaded !
glNormal3b (2): loaded !
glNormal3d (2): loaded !
glNormal3f (2): loaded !
glNormal3i (2): loaded !
glNormal3s (2): loaded !
glNormal3bv (2): loaded !
glNormal3dv (2): loaded !
glNormal3fv (2): loaded !
glNormal3iv (2): loaded !
glNormal3sv (2): loaded !
glIndexd (2): loaded !
glIndexf (2): loaded !
glIndexi (2): loaded !
glIndexs (2): loaded !
glIndexub (1): loaded !
glIndexdv (2): loaded !
glIndexfv (2): loaded !
glIndexiv (2): loaded !
glIndexsv (2): loaded !
glIndexubv (1): loaded !
glColor3b (2): loaded !
glColor3d (2): loaded !
glColor3f (2): loaded !
glColor3i (2): loaded !
glColor3s (2): loaded !
glColor3ub (2): loaded !
glColor3ui (2): loaded !
glColor3us (2): loaded !
glColor4b (2): loaded !
glColor4d (2): loaded !
glColor4f (2): loaded !
glColor4i (2): loaded !
glColor4s (2): loaded !
glColor4ub (2): loaded !
glColor4ui (2): loaded !
glColor4us (2): loaded !
glColor3bv (2): loaded !
glColor3dv (2): loaded !
glColor3fv (2): loaded !
glColor3iv (2): loaded !
glColor3sv (2): loaded !
glColor3ubv (2): loaded !
glColor3uiv (2): loaded !
glColor3usv (2): loaded !
glColor4bv (2): loaded !
glColor4dv (2): loaded !
glColor4fv (2): loaded !
glColor4iv (2): loaded !
glColor4sv (2): loaded !
glColor4ubv (2): loaded !
glColor4uiv (2): loaded !
glColor4usv (2): loaded !
glTexCoord1d (2): loaded !
glTexCoord1f (2): loaded !
glTexCoord1i (2): loaded !
glTexCoord1s (2): loaded !
glTexCoord2d (2): loaded !
glTexCoord2f (2): loaded !
glTexCoord2i (2): loaded !
glTexCoord2s (2): loaded !
glTexCoord3d (2): loaded !
glTexCoord3f (2): loaded !
glTexCoord3i (2): loaded !
glTexCoord3s (2): loaded !
glTexCoord4d (2): loaded !
glTexCoord4f (2): loaded !
glTexCoord4i (2): loaded !
glTexCoord4s (2): loaded !
glTexCoord1dv (2): loaded !
glTexCoord1fv (2): loaded !
glTexCoord1iv (2): loaded !
glTexCoord1sv (2): loaded !
glTexCoord2dv (2): loaded !
glTexCoord2fv (2): loaded !
glTexCoord2iv (2): loaded !
glTexCoord2sv (2): loaded !
glTexCoord3dv (2): loaded !
glTexCoord3fv (2): loaded !
glTexCoord3iv (2): loaded !
glTexCoord3sv (2): loaded !
glTexCoord4dv (2): loaded !
glTexCoord4fv (2): loaded !
glTexCoord4iv (2): loaded !
glTexCoord4sv (2): loaded !
glRasterPos2d (2): loaded !
glRasterPos2f (2): loaded !
glRasterPos2i (2): loaded !
glRasterPos2s (2): loaded !
glRasterPos3d (2): loaded !
glRasterPos3f (2): loaded !
glRasterPos3i (2): loaded !
glRasterPos3s (2): loaded !
glRasterPos4d (2): loaded !
glRasterPos4f (2): loaded !
glRasterPos4i (2): loaded !
glRasterPos4s (2): loaded !
glRasterPos2dv (2): loaded !
glRasterPos2fv (2): loaded !
glRasterPos2iv (2): loaded !
glRasterPos2sv (2): loaded !
glRasterPos3dv (2): loaded !
glRasterPos3fv (2): loaded !
glRasterPos3iv (2): loaded !
glRasterPos3sv (2): loaded !
glRasterPos4dv (2): loaded !
glRasterPos4fv (2): loaded !
glRasterPos4iv (2): loaded !
glRasterPos4sv (2): loaded !
glRectd (2): loaded !
glRectf (2): loaded !
glRecti (2): loaded !
glRects (2): loaded !
glRectdv (2): loaded !
glRectfv (2): loaded !
glRectiv (2): loaded !
glRectsv (2): loaded !
glVertexPointer (1): loaded !
glNormalPointer (1): loaded !
glColorPointer (1): loaded !
glIndexPointer (1): loaded !
glTexCoordPointer (1): loaded !
glEdgeFlagPointer (1): loaded !
glGetPointerv (1): loaded !
glArrayElement (1): loaded !
glDrawArrays (1): loaded !
glDrawElements (1): loaded !
glInterleavedArrays (1): loaded !
glShadeModel (2): loaded !
glLightf (2): loaded !
glLighti (2): loaded !
glLightfv (2): loaded !
glLightiv (2): loaded !
glGetLightfv (2): loaded !
glGetLightiv (2): loaded !
glLightModelf (2): loaded !
glLightModeli (2): loaded !
glLightModelfv (2): loaded !
glLightModeliv (2): loaded !
glMaterialf (2): loaded !
glMateriali (2): loaded !
glMaterialfv (2): loaded !
glMaterialiv (2): loaded !
glGetMaterialfv (2): loaded !
glGetMaterialiv (2): loaded !
glColorMaterial (2): loaded !
glPixelZoom (2): loaded !
glPixelStoref (2): loaded !
glPixelStorei (2): loaded !
glPixelTransferf (2): loaded !
glPixelTransferi (2): loaded !
glPixelMapfv (2): loaded !
glPixelMapuiv (2): loaded !
glPixelMapusv (2): loaded !
glGetPixelMapfv (2): loaded !
glGetPixelMapuiv (2): loaded !
glGetPixelMapusv (2): loaded !
glBitmap (2): loaded !
glReadPixels (2): loaded !
glDrawPixels (2): loaded !
glCopyPixels (2): loaded !
glStencilFunc (2): loaded !
glStencilMask (2): loaded !
glStencilOp (2): loaded !
glClearStencil (2): loaded !
glTexGend (2): loaded !
glTexGenf (2): loaded !
glTexGeni (2): loaded !
glTexGendv (2): loaded !
glTexGenfv (2): loaded !
glTexGeniv (2): loaded !
glGetTexGendv (2): loaded !
glGetTexGenfv (2): loaded !
glGetTexGeniv (2): loaded !
glTexEnvf (2): loaded !
glTexEnvi (2): loaded !
glTexEnvfv (2): loaded !
glTexEnviv (2): loaded !
glGetTexEnvfv (2): loaded !
glGetTexEnviv (2): loaded !
glTexParameterf (2): loaded !
glTexParameteri (2): loaded !
glTexParameterfv (2): loaded !
glTexParameteriv (2): loaded !
glGetTexParameterfv (2): loaded !
glGetTexParameteriv (2): loaded !
glGetTexLevelParameterfv (2): loaded !
glGetTexLevelParameteriv (2): loaded !
glTexImage1D (2): loaded !
glTexImage2D (2): loaded !
glGetTexImage (2): loaded !
glGenTextures (1): loaded !
glDeleteTextures (1): loaded !
glBindTexture (1): loaded !
glPrioritizeTextures (1): loaded !
glAreTexturesResident (1): loaded !
glIsTexture (1): loaded !
glTexSubImage1D (1): loaded !
glTexSubImage2D (1): loaded !
glCopyTexImage1D (1): loaded !
glCopyTexImage2D (1): loaded !
glCopyTexSubImage1D (1): loaded !
glCopyTexSubImage2D (1): loaded !
glMap1d (2): loaded !
glMap1f (2): loaded !
glMap2d (2): loaded !
glMap2f (2): loaded !
glGetMapdv (2): loaded !
glGetMapfv (2): loaded !
glGetMapiv (2): loaded !
glEvalCoord1d (2): loaded !
glEvalCoord1f (2): loaded !
glEvalCoord1dv (2): loaded !
glEvalCoord1fv (2): loaded !
glEvalCoord2d (2): loaded !
glEvalCoord2f (2): loaded !
glEvalCoord2dv (2): loaded !
glEvalCoord2fv (2): loaded !
glMapGrid1d (2): loaded !
glMapGrid1f (2): loaded !
glMapGrid2d (2): loaded !
glMapGrid2f (2): loaded !
glEvalPoint1 (2): loaded !
glEvalPoint2 (2): loaded !
glEvalMesh1 (2): loaded !
glEvalMesh2 (2): loaded !
glFogf (2): loaded !
glFogi (2): loaded !
glFogfv (2): loaded !
glFogiv (2): loaded !
glFeedbackBuffer (2): loaded !
glPassThrough (2): loaded !
glSelectBuffer (2): loaded !
glInitNames (2): loaded !
glLoadName (2): loaded !
glPushName (2): loaded !
glPopName (2): loaded !
glDrawRangeElements (1): loaded !
glTexImage3D (1): loaded !
glTexSubImage3D (1): loaded !
glCopyTexSubImage3D (1): loaded !
glColorTable (1): loaded !
glColorSubTable (1): loaded !
glColorTableParameteriv (1): loaded !
glColorTableParameterfv (1): loaded !
glCopyColorSubTable (1): loaded !
glCopyColorTable (1): loaded !
glGetColorTable (1): loaded !
glGetColorTableParameterfv (1): loaded !
glGetColorTableParameteriv (1): loaded !
glBlendEquation (1): loaded !
glBlendColor (1): loaded !
glHistogram (1): loaded !
glResetHistogram (1): loaded !
glGetHistogram (1): loaded !
glGetHistogramParameterfv (1): loaded !
glGetHistogramParameteriv (1): loaded !
glMinmax (1): loaded !
glResetMinmax (1): loaded !
glGetMinmax (1): loaded !
glGetMinmaxParameterfv (1): loaded !
glGetMinmaxParameteriv (1): loaded !
glConvolutionFilter1D (1): loaded !
glConvolutionFilter2D (1): loaded !
glConvolutionParameterf (1): loaded !
glConvolutionParameterfv (1): loaded !
glConvolutionParameteri (1): loaded !
glConvolutionParameteriv (1): loaded !
glCopyConvolutionFilter1D (1): loaded !
glCopyConvolutionFilter2D (1): loaded !
glGetConvolutionFilter (1): loaded !
glGetConvolutionParameterfv (1): loaded !
glGetConvolutionParameteriv (1): loaded !
glSeparableFilter2D (1): loaded !
glGetSeparableFilter (1): loaded !
glBlendColorEXT (1): loaded !
glPolygonOffsetEXT (2): not implemented !
glTexImage3DEXT (1): loaded !
glTexSubImage3DEXT (1): loaded !
glCopyTexSubImage3DEXT (1): loaded !
glGenTexturesEXT (1): loaded !
glDeleteTexturesEXT (1): loaded !
glBindTextureEXT (1): loaded !
glPrioritizeTexturesEXT (1): loaded !
glAreTexturesResidentEXT (1): loaded !
glIsTextureEXT (1): loaded !
glVertexPointerEXT (1): loaded !
glNormalPointerEXT (1): loaded !
glColorPointerEXT (1): loaded !
glIndexPointerEXT (1): loaded !
glTexCoordPointerEXT (1): loaded !
glEdgeFlagPointerEXT (1): loaded !
glGetPointervEXT (1): loaded !
glArrayElementEXT (1): loaded !
glDrawArraysEXT (1): loaded !
glBlendEquationEXT (1): loaded !
glPointParameterfEXT (1): loaded !
glPointParameterfvEXT (1): loaded !
glColorTableEXT (1): loaded !
glColorSubTableEXT (1): loaded !
glGetColorTableEXT (1): loaded !
glGetColorTableParameterfvEXT (1): loaded !
glGetColorTableParameterivEXT (1): loaded !
glLockArraysEXT (1): loaded !
glUnlockArraysEXT (1): loaded !
glActiveTextureARB (1): loaded !
glClientActiveTextureARB (1): loaded !
glMultiTexCoord1dARB (1): loaded !
glMultiTexCoord1dvARB (1): loaded !
glMultiTexCoord1fARB (1): loaded !
glMultiTexCoord1fvARB (1): loaded !
glMultiTexCoord1iARB (1): loaded !
glMultiTexCoord1ivARB (1): loaded !
glMultiTexCoord1sARB (1): loaded !
glMultiTexCoord1svARB (1): loaded !
glMultiTexCoord2dARB (1): loaded !
glMultiTexCoord2dvARB (1): loaded !
glMultiTexCoord2fARB (1): loaded !
glMultiTexCoord2fvARB (1): loaded !
glMultiTexCoord2iARB (1): loaded !
glMultiTexCoord2ivARB (1): loaded !
glMultiTexCoord2sARB (1): loaded !
glMultiTexCoord2svARB (1): loaded !
glMultiTexCoord3dARB (1): loaded !
glMultiTexCoord3dvARB (1): loaded !
glMultiTexCoord3fARB (1): loaded !
glMultiTexCoord3fvARB (1): loaded !
glMultiTexCoord3iARB (1): loaded !
glMultiTexCoord3ivARB (1): loaded !
glMultiTexCoord3sARB (1): loaded !
glMultiTexCoord3svARB (1): loaded !
glMultiTexCoord4dARB (1): loaded !
glMultiTexCoord4dvARB (1): loaded !
glMultiTexCoord4fARB (1): loaded !
glMultiTexCoord4fvARB (1): loaded !
glMultiTexCoord4iARB (1): loaded !
glMultiTexCoord4ivARB (1): loaded !
glMultiTexCoord4sARB (1): loaded !
glMultiTexCoord4svARB (1): loaded !
GL4Java - LGPL-Version
-------------------------------------------------
-------------------------------------------------
Java-Class : GL4Java.GLContext
: Version: 2.5.0.0
Vendor : Jausoft - Sven Goethel Software Development
Native-Library : GL4Java.GLContext
Version: 2.5.0.0
Vendor : Jausoft - Sven Goethel Software Development
-------------------------------------------------
Java-Class : GL4Java.GLFunc impl.
: Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
Native-Library : GL4Java.GLFunc impl.
Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
-------------------------------------------------
Java-Class : GL4Java.GLUFunc impl.
: Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
Native-Library : GL4Java.GLUFunc impl.
Version: 2.4.1.0
Vendor : Jausoft - Sven Goethel Software Development
-------------------------------------------------
OpenGL - Versions
-----------------------------------------------
GL VENDOR: NVIDIA Corporation
GL RENDERER: GeForce3/AGP/SSE
GL VERSION: 1.3.0
GL EXTENSIONS: GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture
GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_ARB_texture_cube_map GL_ARB_texture_env_add
GL_ARB_texture_env_combine GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix GL_S3_s3tc GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array GL_EXT_draw_range_elements GL_EXT_fog_coord
GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters
GL_EXT_rescale_normal GL_EXT_secondary_color
GL_EXT_separate_specular_color GL_EXT_shared_texture_palette
GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc
GL_EXT_texture_edge_clamp GL_EXT_texture_env_add
GL_EXT_texture_env_combine GL_EXT_texture_env_dot3
GL_EXT_texture_cube_map GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_object
GL_EXT_vertex_array GL_EXT_vertex_weighting
GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square
GL_NV_copy_depth_to_color GL_NV_evaluators GL_NV_fence
GL_NV_fog_distance GL_NV_light_max_exponent
GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil
GL_NV_register_combiners GL_NV_register_combiners2
GL_NV_texgen_reflection GL_NV_texture_compression_vtc
GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_texture_shader
GL_NV_texture_shader2 GL_NV_vertex_array_range GL_NV_vertex_array_range2
GL_NV_vertex_program GL_SGIS_generate_mipmap GL_SGIS_multitexture
GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow
GL_WIN_swap_hint WGL_EXT_swap_control
GLU VERSION: 1.2.2.0 Microsoft Corporation
GLU EXTENSIONS: GL_EXT_bgra
OpenGL - Function Test (438 Functions)
-----------------------------------------------
OK : glClearIndex
OK : glClearColor
OK : glClear
OK : glIndexMask
OK : glColorMask
OK : glAlphaFunc
OK : glBlendFunc
OK : glLogicOp
OK : glCullFace
OK : glFrontFace
OK : glPointSize
OK : glLineWidth
OK : glLineStipple
OK : glPolygonMode
OK : glPolygonOffset
OK : glPolygonStipple
OK : glGetPolygonStipple
OK : glEdgeFlag
OK : glEdgeFlagv
OK : glScissor
OK : glClipPlane
OK : glGetClipPlane
OK : glDrawBuffer
OK : glReadBuffer
OK : glEnable
OK : glDisable
OK : glIsEnabled
OK : glEnableClientState
OK : glDisableClientState
OK : glGetBooleanv
OK : glGetDoublev
OK : glGetFloatv
OK : glGetIntegerv
OK : glPushAttrib
OK : glPopAttrib
OK : glPushClientAttrib
OK : glPopClientAttrib
OK : glRenderMode
OK : glGetError
OK : glFinish
OK : glFlush
OK : glHint
OK : glClearDepth
OK : glDepthFunc
OK : glDepthMask
OK : glDepthRange
OK : glClearAccum
OK : glAccum
OK : glMatrixMode
OK : glOrtho
OK : glFrustum
OK : glViewport
OK : glPushMatrix
OK : glPopMatrix
OK : glLoadIdentity
OK : glLoadMatrixd
OK : glLoadMatrixf
OK : glMultMatrixd
OK : glMultMatrixf
OK : glRotated
OK : glRotatef
OK : glScaled
OK : glScalef
OK : glTranslated
OK : glTranslatef
OK : glIsList
OK : glDeleteLists
OK : glGenLists
OK : glNewList
OK : glEndList
OK : glCallList
OK : glCallLists
OK : glListBase
OK : glBegin
OK : glEnd
OK : glVertex2d
OK : glVertex2f
OK : glVertex2i
OK : glVertex2s
OK : glVertex3d
OK : glVertex3f
OK : glVertex3i
OK : glVertex3s
OK : glVertex4d
OK : glVertex4f
OK : glVertex4i
OK : glVertex4s
OK : glVertex2dv
OK : glVertex2fv
OK : glVertex2iv
OK : glVertex2sv
OK : glVertex3dv
OK : glVertex3fv
OK : glVertex3iv
OK : glVertex3sv
OK : glVertex4dv
OK : glVertex4fv
OK : glVertex4iv
OK : glVertex4sv
OK : glNormal3b
OK : glNormal3d
OK : glNormal3f
OK : glNormal3i
OK : glNormal3s
OK : glNormal3bv
OK : glNormal3dv
OK : glNormal3fv
OK : glNormal3iv
OK : glNormal3sv
OK : glIndexd
OK : glIndexf
OK : glIndexi
OK : glIndexs
OK : glIndexub
OK : glIndexdv
OK : glIndexfv
OK : glIndexiv
OK : glIndexsv
OK : glIndexubv
OK : glColor3b
OK : glColor3d
OK : glColor3f
OK : glColor3i
OK : glColor3s
OK : glColor3ub
OK : glColor3ui
OK : glColor3us
OK : glColor4b
OK : glColor4d
OK : glColor4f
OK : glColor4i
OK : glColor4s
OK : glColor4ub
OK : glColor4ui
OK : glColor4us
OK : glColor3bv
OK : glColor3dv
OK : glColor3fv
OK : glColor3iv
OK : glColor3sv
OK : glColor3ubv
OK : glColor3uiv
OK : glColor3usv
OK : glColor4bv
OK : glColor4dv
OK : glColor4fv
OK : glColor4iv
OK : glColor4sv
OK : glColor4ubv
OK : glColor4uiv
OK : glColor4usv
OK : glTexCoord1d
OK : glTexCoord1f
OK : glTexCoord1i
OK : glTexCoord1s
OK : glTexCoord2d
OK : glTexCoord2f
OK : glTexCoord2i
OK : glTexCoord2s
OK : glTexCoord3d
OK : glTexCoord3f
OK : glTexCoord3i
OK : glTexCoord3s
OK : glTexCoord4d
OK : glTexCoord4f
OK : glTexCoord4i
OK : glTexCoord4s
OK : glTexCoord1dv
OK : glTexCoord1fv
OK : glTexCoord1iv
OK : glTexCoord1sv
OK : glTexCoord2dv
OK : glTexCoord2fv
OK : glTexCoord2iv
OK : glTexCoord2sv
OK : glTexCoord3dv
OK : glTexCoord3fv
OK : glTexCoord3iv
OK : glTexCoord3sv
OK : glTexCoord4dv
OK : glTexCoord4fv
OK : glTexCoord4iv
OK : glTexCoord4sv
OK : glRasterPos2d
OK : glRasterPos2f
OK : glRasterPos2i
OK : glRasterPos2s
OK : glRasterPos3d
OK : glRasterPos3f
OK : glRasterPos3i
OK : glRasterPos3s
OK : glRasterPos4d
OK : glRasterPos4f
OK : glRasterPos4i
OK : glRasterPos4s
OK : glRasterPos2dv
OK : glRasterPos2fv
OK : glRasterPos2iv
OK : glRasterPos2sv
OK : glRasterPos3dv
OK : glRasterPos3fv
OK : glRasterPos3iv
OK : glRasterPos3sv
OK : glRasterPos4dv
OK : glRasterPos4fv
OK : glRasterPos4iv
OK : glRasterPos4sv
OK : glRectd
OK : glRectf
OK : glRecti
OK : glRects
OK : glRectdv
OK : glRectfv
OK : glRectiv
OK : glRectsv
OK : glVertexPointer
OK : glNormalPointer
OK : glColorPointer
OK : glIndexPointer
OK : glTexCoordPointer
OK : glEdgeFlagPointer
OK : glGetPointerv
OK : glArrayElement
OK : glDrawArrays
OK : glDrawElements
OK : glInterleavedArrays
OK : glShadeModel
OK : glLightf
OK : glLighti
OK : glLightfv
OK : glLightiv
OK : glGetLightfv
OK : glGetLightiv
OK : glLightModelf
OK : glLightModeli
OK : glLightModelfv
OK : glLightModeliv
OK : glMaterialf
OK : glMateriali
OK : glMaterialfv
OK : glMaterialiv
OK : glGetMaterialfv
OK : glGetMaterialiv
OK : glColorMaterial
OK : glPixelZoom
OK : glPixelStoref
OK : glPixelStorei
OK : glPixelTransferf
OK : glPixelTransferi
OK : glPixelMapfv
OK : glPixelMapuiv
OK : glPixelMapusv
OK : glGetPixelMapfv
OK : glGetPixelMapuiv
OK : glGetPixelMapusv
OK : glBitmap
OK : glReadPixels
OK : glDrawPixels
OK : glCopyPixels
OK : glStencilFunc
OK : glStencilMask
OK : glStencilOp
OK : glClearStencil
OK : glTexGend
OK : glTexGenf
OK : glTexGeni
OK : glTexGendv
OK : glTexGenfv
OK : glTexGeniv
OK : glGetTexGendv
OK : glGetTexGenfv
OK : glGetTexGeniv
OK : glTexEnvf
OK : glTexEnvi
OK : glTexEnvfv
OK : glTexEnviv
OK : glGetTexEnvfv
OK : glGetTexEnviv
OK : glTexParameterf
OK : glTexParameteri
OK : glTexParameterfv
OK : glTexParameteriv
OK : glGetTexParameterfv
OK : glGetTexParameteriv
OK : glGetTexLevelParameterfv
OK : glGetTexLevelParameteriv
OK : glTexImage1D
OK : glTexImage2D
OK : glGetTexImage
OK : glGenTextures
OK : glDeleteTextures
OK : glBindTexture
OK : glPrioritizeTextures
OK : glAreTexturesResident
OK : glIsTexture
OK : glTexSubImage1D
OK : glTexSubImage2D
OK : glCopyTexImage1D
OK : glCopyTexImage2D
OK : glCopyTexSubImage1D
OK : glCopyTexSubImage2D
OK : glMap1d
OK : glMap1f
OK : glMap2d
OK : glMap2f
OK : glGetMapdv
OK : glGetMapfv
OK : glGetMapiv
OK : glEvalCoord1d
OK : glEvalCoord1f
OK : glEvalCoord1dv
OK : glEvalCoord1fv
OK : glEvalCoord2d
OK : glEvalCoord2f
OK : glEvalCoord2dv
OK : glEvalCoord2fv
OK : glMapGrid1d
OK : glMapGrid1f
OK : glMapGrid2d
OK : glMapGrid2f
OK : glEvalPoint1
OK : glEvalPoint2
OK : glEvalMesh1
OK : glEvalMesh2
OK : glFogf
OK : glFogi
OK : glFogfv
OK : glFogiv
OK : glFeedbackBuffer
OK : glPassThrough
OK : glSelectBuffer
OK : glInitNames
OK : glLoadName
OK : glPushName
OK : glPopName
OK : glDrawRangeElements
OK : glTexImage3D
OK : glTexSubImage3D
OK : glCopyTexSubImage3D
OK : glColorTable
OK : glColorSubTable
OK : glColorTableParameteriv
OK : glColorTableParameterfv
OK : glCopyColorSubTable
OK : glCopyColorTable
OK : glGetColorTable
OK : glGetColorTableParameterfv
OK : glGetColorTableParameteriv
OK : glBlendEquation
OK : glBlendColor
OK : glHistogram
OK : glResetHistogram
OK : glGetHistogram
OK : glGetHistogramParameterfv
OK : glGetHistogramParameteriv
OK : glMinmax
OK : glResetMinmax
OK : glGetMinmax
OK : glGetMinmaxParameterfv
OK : glGetMinmaxParameteriv
OK : glConvolutionFilter1D
OK : glConvolutionFilter2D
OK : glConvolutionParameterf
OK : glConvolutionParameterfv
OK : glConvolutionParameteri
OK : glConvolutionParameteriv
OK : glCopyConvolutionFilter1D
OK : glCopyConvolutionFilter2D
OK : glGetConvolutionFilter
OK : glGetConvolutionParameterfv
OK : glGetConvolutionParameteriv
OK : glSeparableFilter2D
OK : glGetSeparableFilter
OK : glBlendColorEXT
NOPE: glPolygonOffsetEXT
OK : glTexImage3DEXT
OK : glTexSubImage3DEXT
OK : glCopyTexSubImage3DEXT
OK : glGenTexturesEXT
OK : glDeleteTexturesEXT
OK : glBindTextureEXT
OK : glPrioritizeTexturesEXT
OK : glAreTexturesResidentEXT
OK : glIsTextureEXT
OK : glVertexPointerEXT
OK : glNormalPointerEXT
OK : glColorPointerEXT
OK : glIndexPointerEXT
OK : glTexCoordPointerEXT
OK : glEdgeFlagPointerEXT
OK : glGetPointervEXT
OK : glArrayElementEXT
OK : glDrawArraysEXT
OK : glBlendEquationEXT
OK : glPointParameterfEXT
OK : glPointParameterfvEXT
OK : glColorTableEXT
OK : glColorSubTableEXT
OK : glGetColorTableEXT
OK : glGetColorTableParameterfvEXT
OK : glGetColorTableParameterivEXT
OK : glLockArraysEXT
OK : glUnlockArraysEXT
OK : glActiveTextureARB
OK : glClientActiveTextureARB
OK : glMultiTexCoord1dARB
OK : glMultiTexCoord1dvARB
OK : glMultiTexCoord1fARB
OK : glMultiTexCoord1fvARB
OK : glMultiTexCoord1iARB
OK : glMultiTexCoord1ivARB
OK : glMultiTexCoord1sARB
OK : glMultiTexCoord1svARB
OK : glMultiTexCoord2dARB
OK : glMultiTexCoord2dvARB
OK : glMultiTexCoord2fARB
OK : glMultiTexCoord2fvARB
OK : glMultiTexCoord2iARB
OK : glMultiTexCoord2ivARB
OK : glMultiTexCoord2sARB
OK : glMultiTexCoord2svARB
OK : glMultiTexCoord3dARB
OK : glMultiTexCoord3dvARB
OK : glMultiTexCoord3fARB
OK : glMultiTexCoord3fvARB
OK : glMultiTexCoord3iARB
OK : glMultiTexCoord3ivARB
OK : glMultiTexCoord3sARB
OK : glMultiTexCoord3svARB
OK : glMultiTexCoord4dARB
OK : glMultiTexCoord4dvARB
OK : glMultiTexCoord4fARB
OK : glMultiTexCoord4fvARB
OK : glMultiTexCoord4iARB
OK : glMultiTexCoord4ivARB
OK : glMultiTexCoord4sARB
OK : glMultiTexCoord4svARB
C:\jbuilder5\jdk1.3\jre\lib\ext\2.5.2>java -classpath gl4java.jar
gl4java.GLContext -infotxt > err
sizes:
jint=4
HGLRC=4
HDC=4
GLbyte 1
GLshort 2
GLint 4
GLfloat 4
GLdouble 8
GLubyte 1
GLboolean 1
GLushort 2
GLuint 4
GLenum 4
GLbitfield 4
jboolean 1
jbyte 1
jchar 2
jshort 2
jint 4
jlong 8
jfloat 4
jdouble 8
received pData : -2029976199
USER CHOOSED PIXELFORMAT (TRYING):
Pixel format 0
dwFlags - 0x1025
PFD_DOUBLEBUFFER
PFD_DRAW_TO_WINDOW
PFD_SUPPORT_OPENGL
PFD_GENERIC_ACCELERATED
iPixelType - 0
PGD_TYPE_RGBA
cColorBits - 32
cRedBits - 0
cRedShift - 0
cGreenBits - 0
cGreenShift - 0
cBlueBits - 0
cBlueShift - 0
cAlphaBits - 0
cAlphaShift - 0x0
cAccumBits - 0
cAccumRedBits - 0
cAccumGreenBits - 0
cAccumBlueBits - 0
cAccumAlphaBits - 0
cDepthBits - 32
cStencilBits - 0
cAuxBuffers - 0
iLayerType - 0
bReserved - 0
dwLayerMask - 0x0
dwVisibleMask - 0x0
dwDamageMask - 0x0
PIXELFORMAT OF GL-Context SETTINGS:
Pixel format 3
dwFlags - 0x225
PFD_DOUBLEBUFFER
PFD_DRAW_TO_WINDOW
PFD_SUPPORT_OPENGL
iPixelType - 0
PGD_TYPE_RGBA
cColorBits - 32
cRedBits - 8
cRedShift - 16
cGreenBits - 8
cGreenShift - 8
cBlueBits - 8
cBlueShift - 0
cAlphaBits - 0
cAlphaShift - 0x0
cAccumBits - 64
cAccumRedBits - 16
cAccumGreenBits - 16
cAccumBlueBits - 16
cAccumAlphaBits - 16
cDepthBits - 24
cStencilBits - 0
cAuxBuffers - 0
iLayerType - 0
bReserved - 0
dwLayerMask - 0x0
dwVisibleMask - 0x0
dwDamageMask - 0x0
go and set windowHandle thisWin : -2029976199; 0x87010579
go and set pixmapHandle pix: 7743540; 0x762834
go and set gc : 65536, 0x10000
-Aaron
|
|
From: Sven G. <sgo...@ja...> - 2001-12-17 22:53:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 17 December 2001 21:50, gerard ziemski wrote: > hi guys, > > does any one know what happen to the JFreeD - the open source > implementation of Java3D that can run on top of gl4java? any > archives that still have it? > ok, i have put the latest version i do have of it online .. http://www.jausoft.com/Files/Java/1.1.X/GL4Java-Stuff/ if somebody has a newer more up to date version, don't hesitate and send it to me (sources only). then i can put this online .. 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 iD8DBQE8HndpHdOA30NoFAARAhKZAKCn/ChjyDL6FWh3EerPV5rZmGGvOwCgjQFH /hq4szCkgRj4S9wXYxGixoA= =Xlpg -----END PGP SIGNATURE----- |
|
From: gerard z. <gzi...@ap...> - 2001-12-17 20:51:01
|
hi guys, does any one know what happen to the JFreeD - the open source implementation of Java3D that can run on top of gl4java? any archives that still have it? i played with it about 2 years ago and it looked promising. i can't find it anywhere now though. cheers |
|
From: Kenneth B. R. <kbr...@al...> - 2001-12-17 15:56:53
|
> I have a class that extends GLCanvas, and I have the functions related with > tha canvas, > preinit, init, display, ... > > With GLDrawableFactory I can create a GLCanvas, but how can I use the > functions of my class, > that extends GLCanvas, there are any examples of use? You put that functionality into a class implementing GLEventListener instead and set the GLEventListener of the GLDrawable. See demos/new-style.txt and demos/MiscDemos/gears.java for an example. |
|
From: Ricardo <rio...@ya...> - 2001-12-17 15:08:56
|
-----Mensaje original----- De: Kenneth B. Russell [mailto:kbr...@al...] Enviado el: viernes, 14 de diciembre de 2001 5:02 Para: Ricardo CC: gl4...@li... Asunto: Re: [gl4java-usergroup] DEPTH BUFFER > How can I change the number of bits of the depth buffer. > I have used: > GLContext kj =this.getGLContext(); > GLCapabilities lk = kj.getGLCapabilities(); > lk.setDepthBits(32); This definitely won't work; you need to set this before you create the context. For example, use the GLDrawableFactory and set up the GLCapabilities when you call createGLAnimCanvas. However, I'm not sure what depth buffer sizes most current hardware supports. I think the GLDrawableFactory will return null if the requested depth can't be satisfied, but am not sure. I have a class that extends GLCanvas, and I have the functions related with tha canvas, preinit, init, display, ... With GLDrawableFactory I can create a GLCanvas, but how can I use the functions of my class, that extends GLCanvas, there are any examples of use? Thanks _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
787 messages has been excluded from this view by a project administrator.
