Menu
▾
▴
gl4java-usergroup
|
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-10 10:19:39
|
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 > > |
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-11 03:07:42
|
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 |
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-12 19:09:36
|
Please send all questions to the usergroup list. > Do you use an IDE for Java, and if so which one? Historically > I've used emaces and the command line, but since I've used > Visual Studio from microsoft for the last couple of years I've > grown quite fond if the integrated debugger and class browser > and such. I've tried most of the free java IDE's that run on > linux but none of them feel very good. I personally currently use emacs and javac. Based on personal experience and others' recommendations I'd recommend first JBuilder and CodeGuide. I've also used Forte for Java and Visual Cafe in the past; VC had a fast Java compiler (written in C rather than Java, unfortunately) and a fairly good debugger. Forte for Java was not bad, but I had trouble figuring out how to run under the debugger in the early version I used. This has probably improved in recent versions. |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-29 09:33:19
|
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 > > |
|
From: Mark M. <pat...@lm...> - 2002-01-29 23:15:16
|
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? |
|
From: Mark M. <pat...@lm...> - 2002-02-07 21:56:44
|
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 |
|
From: Pepijn V. E. <pep...@lu...> - 2002-02-08 07:26:14
|
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 > > |
|
From: Mark M. <pat...@lm...> - 2002-03-19 00:14:24
|
Pepijn, Do you know if anyone has incorporated your fixes into the official GL4Java yet? We had a consistant crash in native code or freezing of our application, and we isolated it to tesselator calls in GL4Java. Then we swtiched to deleting our used tesselator and creating a new one for each use (as opposed to reusing the same tesselator for more than one tesselation and being efficient about things), our crashing went away. I am guessing your fixes may have prevented our crashing, and would allow us to reuse the same tesselator for more than one tesselation. -Mark M Pepijn Van Eeckhoudt wrote: > 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 > > > > |
|
From: Pepijn V. E. <pep...@lu...> - 2002-03-19 14:06:53
|
Mark, The fixes I made haven't been incorporated into the official gl4java. I asked on this list if and how I should send these patches to sven or kurt, but I didn't get any reply on that question. I can send you the fixes if you want, but it would be better to integrate them into the official release. The fix I made is a workaround for the one tesselator limit and the memory corruption that can occur when tesselating large polygons. In my application I use two tesselators in parallel and I reuse them constantly, so I guess this should work for you too. Pepijn Van Eeckhoudt ----- Original Message ----- From: "Mark Montana" <pat...@lm...> To: "Pepijn Van Eeckhoudt" <pep...@lu...> Cc: "gluser" <gl4...@li...>; "Duffy, Roy" <roy...@lm...> Sent: Tuesday, 19 March, 2002 01:14 Subject: [gl4java-usergroup] GC Bug - fix incorporated? > Pepijn, > > Do you know if anyone has incorporated your fixes into the official GL4Java yet? We had a > consistant crash in native code or freezing of our application, and we isolated it to > tesselator calls in GL4Java. Then we swtiched to deleting our used tesselator and creating a > new one for each use (as opposed to reusing the same tesselator for more than one tesselation > and being efficient about things), our crashing went away. > > I am guessing your fixes may have prevented our crashing, and would allow us to reuse the same > tesselator for more than one tesselation. > > -Mark M > > Pepijn Van Eeckhoudt wrote: > > > 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 > > > > > > > > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > |
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-30 16:42:46
|
> 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. |
|
From: Pepijn V. E. <pep...@lu...> - 2002-02-01 09:31:38
|
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 > > |
|
From: Kenneth B. R. <kbr...@al...> - 2002-02-03 02:49:51
|
> 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. |
|
From: Pepijn V. E. <pep...@lu...> - 2002-02-04 07:59:42
|
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 > > |
|
From: Kenneth B. R. <kbr...@al...> - 2002-02-08 16:08:13
|
> I checked those scripts, but the only thing they do is filter out the > lines containing GL[U]API and replace some strings. I ran the prepare > script again myself and glGetString is still in gl-proto-auto.orig. > However in gl-proto-auto.orig.h there's no sign of glGetString. So my > guess is you have to manually remove the functions that shouldn't be > autogenerated... Can anyone confirm this? If it's so, I'll write a small > script that reads a file containing the functions to be removed and > removes these automatically from the .orig file. Sven can confirm this 100% but I'll suggest to please write such a script as it doesn't appear (to me) to exist yet. |
|
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: 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: Sven G. <sgo...@ja...> - 2002-01-09 10:23:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 January 2002 10:42, Pepijn Van Eeckhoudt wrote: > If I wanted to change the native code for a standard opengl function > (for instance the glu tesselator stuff), is it enough to add my own > implementations to the files in C2J\manual. YES please read my latest explanation I send to the mailinglist, see below .. > From the makefile it seems > like the auto generated stuff is put together with the manual file using > cat, so I assume you would have a duplicate function declaration then. where is the duplicate ? nono, it just depends on your point of view. for me, the generated sources (C2J'ed and cat'ed) placed to gl4java/ and CNativeCode/ are not kinda temporaery files .. the true sources within C2J/manual, e.g. for gl4java/GLUFunc14JauJNI.java, are the origin ones ! or may be i misunderstood you, so please gimme more details ! > Or did I miss something? If I'm correct, then how sould I add a manual > implementation for a gl function? like i mentions before (see below) .. > > Pepijn Van Eeckhoudt > > Sven Goethel wrote: <snip> > > 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 iD8DBQE8PBoRHdOA30NoFAARAmZZAJwMEFkRHaVBqEmK3AA2MaTOtVT9KgCgkVO+ 84T+4Y0FCr02cRS8HIjAAWQ= =dMkU -----END PGP SIGNATURE----- |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-09 10:55:54
|
Sorry if i wasn't clear. In the makefile in the C2J directory there are rules like: ../CNativeCode/OpenGLU_JauJNI_funcs.c: C2J.class \ warning.skel \ ../CNativeCode/OpenGLU_funcs.c.skel \ manual/glu-manualCodedImplJNI.c \ glu-proto-auto.c cat warning.skel \ ../CNativeCode/OpenGLU_funcs.c.skel \ manual/glu-manualCodedImplJNI.c \ glu-proto-auto.c \ > ../CNativeCode/OpenGLU_JauJNI_funcs.c Which cats the C2J generated file (glu-proto-auto.c) and the manual file (glu-manualCodedImplJNI.c) together. The auto generated file however already contains an implementation for a lot of glu functions (for instance "JNIEXPORT void JNICALL Java_gl4java_GLUFuncJauJNI_gluTessVertex__J_3D_3B"). If I put a manually coded implementation for this function in glu-manualCodedImplJNI.c, then the cat'ed file has two implementations of the function in it. Is there a way to do this correctly or do am I mistaken somewhere? Pepijn Van Eeckhoudt Sven Goethel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 09 January 2002 10:42, Pepijn Van Eeckhoudt wrote: > >>If I wanted to change the native code for a standard opengl function >>(for instance the glu tesselator stuff), is it enough to add my own >>implementations to the files in C2J\manual. >> > > YES > > please read my latest explanation I send to the mailinglist, see below .. > > >>From the makefile it seems >>like the auto generated stuff is put together with the manual file using >>cat, so I assume you would have a duplicate function declaration then. >> > > where is the duplicate ? > > nono, it just depends on your point of view. > > for me, the generated sources (C2J'ed and cat'ed) > placed to gl4java/ and CNativeCode/ are not kinda temporaery files .. > > the true sources within C2J/manual, e.g. for gl4java/GLUFunc14JauJNI.java, > are the origin ones ! > > or may be i misunderstood you, so please gimme more details ! > > >>Or did I miss something? If I'm correct, then how sould I add a manual >>implementation for a gl function? >> > > like i mentions before (see below) .. > > >>Pepijn Van Eeckhoudt >> >>Sven Goethel wrote: >> > > <snip> > >>>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 > > iD8DBQE8PBoRHdOA30NoFAARAmZZAJwMEFkRHaVBqEmK3AA2MaTOtVT9KgCgkVO+ > 84T+4Y0FCr02cRS8HIjAAWQ= > =dMkU > -----END PGP SIGNATURE----- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > |
|
From: Sven G. <sgo...@ja...> - 2002-01-09 10:30:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1st of all, PLEASE REPLY TO THE POSTINGS ITSELF, not the digest - so it is more easy to find such archived emails ;-) QUESTION: how can we setup the mailinglist, so the REPLY-TO field is set .. ? On Wednesday 09 January 2002 10:39, Pepijn Van Eeckhoudt wrote: > 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 ;)) <snip> > 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. well, but we should use the new NIO buffers, which solves all such issues for Java 1.4 !! so please mention and anticipate my latest suggestions and help developing it straight forward to offer a quiet nice solution .. i guess this is better than an ugly kinda workaround or manual extra array-copy .. 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 iD8DBQE8PBvFHdOA30NoFAARAh0MAKCDrY7mb1TYlD9dX+y8pnTrkVZDaACeLfqm cpteDQX4JbbWbqzqe53NBzQ= =pl7y -----END PGP SIGNATURE----- |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-09 10:43:45
|
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. Pepijn Van Eeckhoudt Sven Goethel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1st of all, PLEASE REPLY TO THE POSTINGS ITSELF, > not the digest - so it is more easy to find such archived emails ;-) > > QUESTION: how can we setup the mailinglist, so the REPLY-TO field is set .. ? > > On Wednesday 09 January 2002 10:39, Pepijn Van Eeckhoudt wrote: > > >>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 ;)) >> > <snip> > >>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. >> > > well, but we should use the new NIO buffers, > which solves all such issues for Java 1.4 !! > > so please mention and anticipate my latest suggestions > and help developing it straight forward to offer a quiet nice > solution .. > > i guess this is better than an ugly kinda workaround or manual > extra array-copy .. > > 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 > > iD8DBQE8PBvFHdOA30NoFAARAh0MAKCDrY7mb1TYlD9dX+y8pnTrkVZDaACeLfqm > cpteDQX4JbbWbqzqe53NBzQ= > =pl7y > -----END PGP SIGNATURE----- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > |
|
From: Sven G. <sgo...@ja...> - 2002-01-09 11:33:40
|
-----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----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X