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: Sven G. <sgo...@ja...> - 2001-02-21 22:03:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 February 2001 12:47, Thorsten Roemer wrote: > > while I tried an implementation for the swing opengl rendering, > > I started an implementation of the Graphics class, > > which implements it's rendering using OpenGL ;-) > > > > may this will help > > > > I can send this little implementation with a test class, > > but it must be improved .. > > Yes, please send it ... > (I'm also working on an implementation of the Graphics class) > > ciao, Thorsten > yo .. the files are within the demos-package: demos/SwingDemos/test there exist some test's within its own directory, try GLPanel-GLGraphics/GLGraphics.java would be cool, if someone tries to make it useful ! bye, sven > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > http://lists.sourceforge.net/lists/listinfo/gl4java-usergroup - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6lDshHdOA30NoFAARAobEAJwKGAt8L0A/rhsQTHl403bblQHkEACgj9rX 0SUfOYWvrSScxRL73VNVOmE= =Ubg6 -----END PGP SIGNATURE----- |
|
From: Thorsten R. <ro...@iv...> - 2001-02-21 11:46:48
|
> while I tried an implementation for the swing opengl rendering, > I started an implementation of the Graphics class, > which implements it's rendering using OpenGL ;-) > > may this will help > > I can send this little implementation with a test class, > but it must be improved .. Yes, please send it ... (I'm also working on an implementation of the Graphics class) ciao, Thorsten |
|
From: Joe & B. H. <jhu...@gt...> - 2001-02-21 04:57:52
|
>>> I want to do this because it is often easier to draw simple geometry and >>> images using the AWT methods than it is to try and do the same thing >>> through OpenGL. It would be really nice if I could draw AWT graphics >>> elements over top of an OpenGL scene. > > There are several C/C++ libraries which use OpenGL to draw non-3D > images which you might be able to borrow from or port pieces of > to make this easier. See GLUI, for example: > http://www.cs.unc.edu/~rademach/glui/ Thanks for the info! I'll take a look. Ad astra, Joe Huwaldt |
|
From: Joe & B. H. <jhu...@gt...> - 2001-02-21 04:57:35
|
> On Tuesday 20 February 2001 05:42, Joe & Bobbey Huwaldt wrote: >> Sven, >> >> Is there a method by which I can draw on top of a GLCanvas using the >> regular AWT methods? For example, I would like to render a 3D scene using >> GL4Java, then draw some items on top of part of that scene using a regular >> AWT graphics context. My first thought was that I would override paint(), >> but I see that you have prevented that. Did you provide any other way to >> do the same thing? Is it even possible (I haven't looked at the source >> code, so I don't know how the implementation works)? >> > > well .. you can try Graphics g = this.getGraphics() ! > And awt-render _after_ swapping the buffer, > if you use double-buffering. > > This will not work in the current GL4Java up to 2.5.0-test2 > if an new native window is created (see the native debug out info's) ! > > In the upcoming 2.5.0-test3 this should work, if you use the new factory api, > because the java window itself will have all the capabilities needed > while using the JDK 1.3 class GraphicsConfiguration internaly > (-> no more new native window will be created) ! Well, what you have suggested here works for my particular problem, but I have not tested it everywhere yet. I only have one OpenGL window open at a time and I am able to draw onto it without any problems using Java 1.2.2 on Windows 98 and Java 1.1 on MacOS 9. Here is what I was trying to do: http://www.babst.org/~jhuwaldt/3DStuff/VSphere/VSphere.html It's an implementation of the virtual sphere algorithm for intuitive 3D rotation using a 2D input device (mouse). I could have rendered the virtual sphere feedback using OpenGL, but it was so much easier to do it using the AWT. IMHO, my theory is you should try to minimize the usage of OpenGL in your Java programs since it is not very object oriented, isn't 100% portable, is more difficult to support, and I find it generally messy. > well, this is true, e.g. for an overlayed textual info .. Especially for 2D text! Using OpenGL for text is just plain painful. > may be you have to wait for the new version ... I'm a patient man. As long as your doing the work, I'm content to wait. ;-) Ad astra, Joe Huwaldt |
|
From: Sven G. <sgo...@ja...> - 2001-02-20 20:12:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 February 2001 20:58, Kenneth B. Russell wrote: > > > I want to do this because it is often easier to draw simple geometry > > > and images using the AWT methods than it is to try and do the same > > > thing through OpenGL. It would be really nice if I could draw AWT > > > graphics elements over top of an OpenGL scene. > > There are several C/C++ libraries which use OpenGL to draw non-3D > images which you might be able to borrow from or port pieces of > to make this easier. See GLUI, for example: > http://www.cs.unc.edu/~rademach/glui/ > > -Ken > well, I remember ;-): while I tried an implementation for the swing opengl rendering, I started an implementation of the Graphics class, which implements it's rendering using OpenGL ;-) may this will help I can send this little implementation with a test class, but it must be improved .. the most important thing to be improved may the font implementation .. bye, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6ks+THdOA30NoFAARAvxEAJ4+vb2iMZrrJibHzy0QCPD6TIChuQCcCFDy HlMSEz37AqYMnFD/2go17+I= =xKFi -----END PGP SIGNATURE----- |
|
From: Kenneth B. R. <kbr...@al...> - 2001-02-20 19:58:14
|
> On Tuesday 20 February 2001 05:42, Joe & Bobbey Huwaldt wrote: > > > > Is there a method by which I can draw on top of a GLCanvas using the > > regular AWT methods? For example, I would like to render a 3D scene using > > GL4Java, then draw some items on top of part of that scene using a regular > > AWT graphics context. My first thought was that I would override paint(), > > but I see that you have prevented that. Did you provide any other way to > > do the same thing? Is it even possible (I haven't looked at the source > > code, so I don't know how the implementation works)? > > In the upcoming 2.5.0-test3 this should work, if you use the new factory api, > because the java window itself will have all the capabilities needed > while using the JDK 1.3 class GraphicsConfiguration internaly > (-> no more new native window will be created) ! Actually this is not guaranteed to work. The AWT may not be able to draw to the same window being drawn to by OpenGL. I believe the root of the problem is a driver issue on Windows; I think it is illegal to mix Windows GDI and OpenGL calls to the same device context. > > I want to do this because it is often easier to draw simple geometry and > > images using the AWT methods than it is to try and do the same thing > > through OpenGL. It would be really nice if I could draw AWT graphics > > elements over top of an OpenGL scene. There are several C/C++ libraries which use OpenGL to draw non-3D images which you might be able to borrow from or port pieces of to make this easier. See GLUI, for example: http://www.cs.unc.edu/~rademach/glui/ -Ken |
|
From: Sven G. <sgo...@ja...> - 2001-02-20 04:55:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 February 2001 05:42, Joe & Bobbey Huwaldt wrote: > Sven, > > Is there a method by which I can draw on top of a GLCanvas using the > regular AWT methods? For example, I would like to render a 3D scene using > GL4Java, then draw some items on top of part of that scene using a regular > AWT graphics context. My first thought was that I would override paint(), > but I see that you have prevented that. Did you provide any other way to > do the same thing? Is it even possible (I haven't looked at the source > code, so I don't know how the implementation works)? > well .. you can try Graphics g = this.getGraphics() ! And awt-render _after_ swapping the buffer, if you use double-buffering. This will not work in the current GL4Java up to 2.5.0-test2 if an new native window is created (see the native debug out info's) ! In the upcoming 2.5.0-test3 this should work, if you use the new factory api, because the java window itself will have all the capabilities needed while using the JDK 1.3 class GraphicsConfiguration internaly (-> no more new native window will be created) ! > I want to do this because it is often easier to draw simple geometry and > images using the AWT methods than it is to try and do the same thing > through OpenGL. It would be really nice if I could draw AWT graphics > elements over top of an OpenGL scene. > well, this is true, e.g. for an overlayed textual info .. > Thanks for any help you can provide. > may be you have to wait for the new version ... > Ad astra, > > Joe Huwaldt bye, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6kfi1HdOA30NoFAARAtv3AJ9jhsnRAC0d8EwuMZgH4MoJgA4vEQCfUJM0 XPTK2bGRXQoVUJswna5AkTM= =4zkK -----END PGP SIGNATURE----- |
|
From: Artiste on t. W. <a1...@So...> - 2001-02-16 13:16:17
|
Hi everyone, The new 0.3 version of Arkanae is available at perso.club-internet.fr/b_lamy !!!! Arkanae is a 3D RPG game, developped in Java and GL4Java. Enjoy yourself ! A11W |
|
From: <kp...@in...> - 2001-02-14 14:14:00
|
On Wed, 14 Feb 2001 09:18:31 -0300, Felipe Gomes de Carvalho wrote: The attached routine will extract any given frustrum from your current projection matrix. This way it doesn't matter how you set your projection (lookAt, gluOrtho, gluPerpective, etc.) > >How can I get the 6 clipping planes of the viewing frustum, or the 8 >coordinates of the frustum >in world coordinates, using the 4 parameters of the function >gl.gluPerspective(fov,aspect,zNear,zFar) ? > >Thanks!!!! > > > > >_______________________________________________ >gl4java-usergroup mailing list >gl4...@li... >http://lists.sourceforge.net/lists/listinfo/gl4java-usergroup |
|
From: Felipe G. de C. <ka...@in...> - 2001-02-14 13:19:03
|
How can I get the 6 clipping planes of the viewing frustum, or the 8 coordinates of the frustum in world coordinates, using the 4 parameters of the function gl.gluPerspective(fov,aspect,zNear,zFar) ? Thanks!!!! |
|
From: Sven G. <sgo...@ja...> - 2001-02-14 12:07:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, I forgot to say: I have two little shell scripts to help porting your app's to rel-2-5-2-0, which checks: If your MakeCurrent/Free calls are tied: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/GL4Java/GL4Java/demos/GL4JavaCheckMakeCurrentFree.sh?cvsroot=gl4java - so you have to: - encapsulate all your gl* action within MakeCurrent/Free - add gljFree or MakeCurrent right If you use gluNew* calls http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/GL4Java/GL4Java/demos/GL4JavaCheckGluNew.sh?cvsroot=gl4java - so you have to change your l-value to type "long" ! these are integrated in the demos directory .. of yourse, these are korn shell scripts ;-) yours, sven .sourceforge.net/lists/listinfo/gl4java-usergroup - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6inTmHdOA30NoFAARAt+NAJ9IAMWBFAIF59kN75GqT7SEVL1HKwCfbeTE Ld2BoyPXZIHsB9Osii0qjVQ= =ov2w -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-14 11:48:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 February 2001 15:15, Nicolas Cadilhac wrote: > This message was sent from Geocrawler.com by "Nicolas Cadilhac" > <cad...@mi...> > > Thanks for your answer. Just another one to > continue : I monitored dlls loaded when running > my application and I can see that opengl32.dll > and my opengl ati driver are loaded in both cases > (using canvas or JPanel derived classes). Do you > have an idea why it is loaded in the last case > and it is not accelerated ? > Here is a dialog between Kenneth Russel and me about the upcoming JAWT/JDK1.4 and OpenGL[tm] for Java[tm] (former project name: GL4Java) integration. This integration has started with the current test releases of OpenGL[tm] for Java[tm] 2.5.2.0-test2 ! JAWT is supportet now, other things, like GraphicsConfiguration -> Canvas and a better Swing integration may come soon. Kenneth B Russel: > I'm not sure about the interaction with Swing. java.awt.Window is > the first class in the hierarchy which has a constructor taking a > GraphicsConfiguration; this goes down the hierarchy to JFrame, > but not to JPanel, which is of course lightweight. I haven't > looked at the offscreen buffer code in GL4Java so I don't know > whether these visual problems are an issue there. > GL4Java's Swing implementation is very stupid at this time ! It just creates an OpenGL offscreen context, draws in it, then copies everytthing into the swing panel. - Mostly no OpenGL implementation supports hw accelerated offscreen rendering But this will change in the near future, e.g. with glx 1.3 pbuffers, where they said it IS guaranteed to being hw accelerated .. - At this time, the Swing buffer was NOT compatible with the OpenGL offscreen buffer. If not compatible: Rearrangment of pixel config is needed -> manual conversion If compatibel: Just copy ! So the PERFECT future would be the following: - - - Have OpenGL hw accelerated offscreen rendering - - - Find a Swing Buffer Pixel configuration compatible with an OpenGL offscreen buffer pixel configuration - - - Use the OpenGL offscreen Buffer as the Swing JPanel backbuffer (!). - - - Just swap :-) This configuration would provide less overhead and maximum performance, i guess so ! Is this possible ? I guess with the new upcoming so called java.nio package (jdk1.4), we would be able to use OpenGL offscreen buffer ! Then - we need a 1 to 1 interface without overhead to Swing's JPanel backbuffer ! - - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6inBaHdOA30NoFAARAsL9AKCVixzeDLCoxczSbV0XVuELcPdxvwCePD0j HL1KD1FeYzRsS2E8GjSO514= =+Zgp - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6inCVHdOA30NoFAARAq2tAJ0VvZZFVMF8+Bysu7WcPgVUd5MzRACgwwJn hBc8wBGEVSwAHd+PacuD0xM= =jCS7 -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-14 10:12:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 February 2001 12:42, you wrote: > What is necessary to calculate the FPS of an application in Java, using > GL4Java ? > > > Thanks > > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > http://lists.sourceforge.net/lists/listinfo/gl4java-usergroup just look at the implementation of GLAnimCanvas + GLCanvas ! thats all: (t1-t0(/frames := fps, where frames are the number of frames rendered within period [t0..t1] ;-) sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6iln/HdOA30NoFAARAqfgAJwMIp4vRiCRTYpgnR7EFzjU1WCNXwCcD9gi dKAQQdaX972O2QSPaGHKw2c= =8iD6 -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-14 08:35:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A new bugfixed test release is done ! This one is well testable ! Please do so, to make it more stable ! you can get it from: binary-packages: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/binpkg sources, doc's, demo's: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/archive The CVS repository is commited and tagged: rev-2-5-2-0-test2 Experience: ========== Linux 2.4.1, XFree86 4.0.2, kde 2.1 beta2: Command-Line JDK (1.1-1.3, sun, blackdown, ibm(no jawt)): OK ! Indirect DRI (Mesa-Soft 3.3): OK NVidia 0.96: OK See NVidia notes below ! Netscape + Netscape JVM: ERROR ! does not work, because Netscape's JVM implementation on linux looks like not to handle long-types within the JNI API .. ?! Netscape + j2re-1_3_0_01: OK ! Indirect DRI (Mesa-Soft 3.3): OK NVidia 0.96: OK See NVidia notes below ! Konqueror (2.1 beta2): jdk 1.3-sun: ERROR Applet runs, but nothing is visible ! jdk 1.3-ibm (no jawt): OK ! jdk 1.3-blackdown: OK ! Indirect DRI (Mesa-Soft 3.3): OK NVidia 0.96: OK See NVidia notes below ! Win98/WinNT4.0(*): Command-Line JDK (1.1-1.3, sun): OK ! Well, you have to start the java.exe from the <jdk-path>/jre/bin/java.exe Otherwise, the jawt.dll is not found !! BUG in JDK !! IExplorer + MS-JVM buil 3802: OK ! JDirect usage .. JRE 1.3* Plugin + ( IExplorer | Netscape ) OK ! Netscape + Netscape JVM OK ! (*) WinNT 4.0: On my system (servicepack6, nvidia detonator3), i cannot restart the applet ! An read access to adress 0x000000 occures right from NVidia's OGL implementation !! Looks like another bug within NVidia ? See NVidia notes below ! Well, Win98 runs fine NVidia Driver Note's: ================ The Linux 0.96 driver, and may be the winnt4.0 drivers, looks like not being able to handle THREAD's very well ! Example: JVM Process 1: JVM Process 1 - Thread 1: >MakeCurrent() >Free() This Produces many .X.err logs regarding to new created drawables for same thread !(?) If you use the same JVM process, and you start many applets -> native threads, the GL context managment looks like very confused. On Linux the GL rendering went slower and slower ! But a restarted JVM is fast as its first time ! Yes - GL4Java does destroy the glcontext and finalizes well ! comments, ideas are very wellcome ! kind regards, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6ikNcHdOA30NoFAARAhoZAKCEkjmEb8oYuVsMMRXezBOhU/vP9gCgh+Lx JkwKrgR7WwChh8BrulCwANA= =B3cQ -----END PGP SIGNATURE----- |
|
From: Paul J. <pj...@im...> - 2001-02-13 16:23:36
|
unsubscribe -----Original Message----- From: gl4...@li... [mailto:gl4...@li...]On Behalf Of Sven Goethel Sent: Thursday, February 08, 2001 7:14 PM To: gl4java-usergroup Subject: [gl4java-usergroup] Fwd: Re: [Gl4java-development] problems with gljMakeCurrent/gljFree -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you are interesting in, please join the discussion in the "gl4java-development" mailinglist. It is about the performance and thread-safety implementation of GL4Java. E.g.: the need for gljMakeCurrent/gljFree encapsulated gl-calls in the display method ! thanxs sven - ---------- Forwarded Message ---------- Subject: Re: [Gl4java-development] problems with gljMakeCurrent/gljFree Date: Fri, 9 Feb 2001 04:07:21 +0100 From: Sven Goethel <sgo...@ja...> To: gl4...@li... - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, well I have: linux-2.4.1 + i686, XFree86 4.0.2 + GeForce256 +nvidia 0.96-nda-binary-driver (at 32bpp) .X.err: ===== (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients ... (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7758 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7757 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients ... ! no exception ! The problem - you are right - is the call of the gljFree() method, which calls glXMakeCurrent( (Display *)disp, None, NULL ) to free the GLXContext ! The NVidia driver makes a stderr printout of the context numbers .. The reason is, that if you have bound one GLXContext to one thread, and another thread wants to use it, it will fail. There can be only one current GLX context per thread. The reason in the demo's and for the advice to encapsulate your frame renderings within gljMakeCurrent/gljFree is to make the GLX context avaiable for possible other threads. This is more safe. Well, I do not know why the NVidia driver is that verbose :-). The OpenGL manual says, that a call of MakeCurrent should not be very time consuming ! The implementation of gljMakeCurrent only changes the GLXContext, if the current GLXContext is not the one we want to make current ! I have just testet with gears.java (>java gears -perftest): With gljFree() call in end of display method: loading libs(gl, glu): null, null: true useFpsSleep: false useRepaint: false GL VERSION : 1.2.1 GL RENDERER: GeForce 256/AGP/SSE GL VENDOR : NVIDIA Corporation 280 frames in 5.005 seconds = 55.94405594405595 FPS 670 frames in 5.001 seconds = 133.9732053589282 FPS 656 frames in 5.006 seconds = 131.0427487015581 FPS 607 frames in 5.005 seconds = 121.27872127872128 FPS 587 frames in 5.008 seconds = 117.21246006389777 FPS Without gljFree() call in end of display method: loading libs(gl, glu): null, null: true useFpsSleep: false useRepaint: false GL VERSION : 1.2.1 GL RENDERER: GeForce 256/AGP/SSE GL VENDOR : NVIDIA Corporation 3491 frames in 5.0 seconds = 698.2 FPS 4945 frames in 5.0 seconds = 989.0 FPS 4973 frames in 5.0 seconds = 994.6 FPS 4940 frames in 5.0 seconds = 988.0 FPS 4919 frames in 5.001 seconds = 983.6032793441311 FPS 4903 frames in 5.0 seconds = 980.6 FPS 4944 frames in 5.0 seconds = 988.8 FPS Well, this looks like a need to think things over ! This is a performance task and a call for thinking the thread-safe mechanism over ! Ideas ? sven On Friday 09 February 2001 01:35, you wrote: > Hi *, > > here comes rather a feedback than a question... Have fun with my bad > english... 8-) > (I hope it's not off-topic) >(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients > I wonder if somebody else has the same problems: > > I've wrote a tiny test-application, doing nothing but "swapping" front and > back buffer. > (ok, copying back to front buffer via "gljSwap()" - have a look at the > attachment) > > I've got the following log: > > === schnipp === > > [...<java emptyLoop_GLCanvas>...] > > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 0 > clients > (II) NVIDIA(0): purgeCache: Free=0x198f000 Total=0x1fd0000 > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 1 drawables, 1 > clients > emptyLoop_canvas.init > emptyLoop_canvas.reshape > ..(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 2 drawables, 1 > clients > .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3 drawables, 1 > clients > .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 4 drawables, 1 > clients > > [...<counting "drawables" 5-3888> ...] > > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3889 drawables, 1 > clients > # # An unexpected exception has been detected in native code outside the > VM.# Program counter=0x48c3cf8c > # > # Problematic Thread: prio=5 tid=0x81f1498 nid=0x581 runnable > # > Aborted > [thr@elite thr]$ (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, > 3888 drawables, 1 clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > > [...<last line repeats ~20 times> ...] > [...<auto re-init of X/nvidia-driver> ...] > > === schnipp === > > Configuration: > > PC > - AMD Athlon 600MHz > - Asus K7M Mainboard > - 256MB Ram > - Asus GeForce2 32MB V7700 > - SBLive Player 1024 > > Linux Red Hat 7.0 > - XFree 4.01 > - Gnome (default version on redhat 7.0) > - KDE (default version on redhat 7.0) > > OpenGL > - gl4java 2.5.0.0 > - nVidia Drivers 0.94 - 0.96 > > also tried > - Kernel 2.2.18 > - kde 2.01 > - no window manager at all > > So I wrote a tiny "GLAnimCanvas" class for my own. As a result there is no > need to call "gljMakeCurrent()" and "gljFree()" in the display() method > anymore (both are called only once at initialization time). Via a > SwingUtilities like method "invokeLater" and "invokeAndWait" other Threads > are able to use OpenGL commands getting executed in the main Render-Thread. > Now no more crashes after two days of running tests. Then I studied the > differences between the class implementations. > > My thesis: It look's like something (i.e. the nvidia driver, X, or > whatever) doesn't "like" the gljMakeCurrent()/gljFree() combination called > to often. What is the reason having to call both methods in > GLAnimCanvas.display() every frame? > > Any comments ? > [ ] what a hero! ;-) > [ ] nice to know > [ ] what a pain to read > [ ] text to long > [ ] never send attachments > [ ] just get away > > ciao, Thorsten - - ---------------------------------------- Content-Type: application/octet-stream; charset="iso-8859-1"; name="emptyLoop_GLCanvas.java" Content-Transfer-Encoding: quoted-printable Content-Description: - - ---------------------------------------- - - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6g17rHdOA30NoFAARAnG2AKCykVtWJdRe+wwuYlG8cuBnlpgx1wCgiPNZ 2apDQPgaBYGFrRB+Cs6wlxA= =mQed - -----END PGP SIGNATURE----- _______________________________________________ Gl4java-development mailing list Gl4...@li... http://lists.sourceforge.net/lists/listinfo/gl4java-development - ------------------------------------------------------- - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6g2BnHdOA30NoFAARAuXXAJwP8fDdirLAjNggWokllgga3+IndgCgk8ez sbthD0WMFiI6C4wPkZzGQKY= =mz59 -----END PGP SIGNATURE----- _______________________________________________ gl4java-usergroup mailing list gl4...@li... http://lists.sourceforge.net/lists/listinfo/gl4java-usergroup |
|
From: <kp...@in...> - 2001-02-13 14:15:37
|
On Tue, 13 Feb 2001 08:42:59 -0300, Felipe Gomes de Carvalho wrote:
>What is necessary to calculate the FPS of an application in Java, using GL4Java ?
Simple version (in your code that extends GLAnimCanvas)
stopFpsCounter();
int fps=(int)(getFps()); // Fractions are only theoretical.
resetFpsCounter();
Extended version, draws our fps upper-right - and updates only every
second:
private long lastfpscount=0;
private String fpstext="0 fps";
private String verticetext="0 vertices";
private String facetext="0 faces";
private void drawfps() {
if (System.currentTimeMillis()-lastfpscount>1000) {
stopFpsCounter();
fpstext=(int)(getFps())+" fps";
lastfpscount=System.currentTimeMillis();
resetFpsCounter();
}
float xoffset=(float)global.screenwidth-100.0f; // (pixels)
gl.glPushAttrib(GL_DEPTH_BUFFER_BIT|GL_ENABLE_BIT|GL_FOG_BIT|GL_LIGHTING
_BIT|GL_DEPTH_BUFFER_BIT);
gl.glPushMatrix();
gl.glLoadIdentity();
gl.glMatrixMode(GL_PROJECTION);
gl.glPushMatrix();
gl.glLoadIdentity ();
gl.glOrtho(0, global.screenwidth, global.screenheight, 0,
-99999, 99999);
gl.glDisable(GL_DEPTH_TEST);
gl.glDisable(GL_TEXTURE_2D);
gl.glDisable(GL_LIGHTING);
gl.glColor3f(1f,1f,1f);
gl.glRasterPos2f(xoffset,12.0f);
glut.glutBitmapString(glut.GLUT_BITMAP_HELVETICA_10,fpstext);
gl.glRasterPos2f(xoffset,26.0f);
glut.glutBitmapString(glut.GLUT_BITMAP_HELVETICA_10,verticetext);
gl.glRasterPos2f(xoffset,40.0f);
glut.glutBitmapString(glut.GLUT_BITMAP_HELVETICA_10,facetext);
gl.glPopMatrix();
gl.glMatrixMode(GL_MODELVIEW);
gl.glPopMatrix();
gl.glPopAttrib();
}
>
>
>Thanks
|
|
From: Felipe G. de C. <ka...@in...> - 2001-02-13 12:43:31
|
What is necessary to calculate the FPS of an application in Java, using GL4Java ? Thanks |
|
From: Sven G. <sgo...@ja...> - 2001-02-13 06:09:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A test release is done ! The new revision may be incompatible with the previous, because: - The GLUFunc.gluNew* etc. methods uses the long type for the reference holder for quadric, tesselation, .. (old: int type) ! This is, because this new revision is completly 64bit clean ! All native reference holders are long ! - You do not encapsulate your OpenGL calls within GLContext.gljMakeCurrent <your render code> GLContext.gljFree e.g. within the GLCanvas.display method: glj.gljMakeCurrent(); // lock GL Context gl.glBegin(); gl.glEnd(); glj.gljSwap(); glj.gljFree(); // release GL Context All the demo's have been updated in the new test release, to work with 2.5.2.0 ! This new Version try's to use JDK >=1.3's JAWT API to handle with the native window ! The new library, which uses this is called "GL4JavaJauGljJNI13" ! I do have problems with IBM's JDK 1.3: No library "jawt" (linux: libjawt.so, win32: jawt.dll) exists at all ! I do have problems with Sun's JDK 1.3 for Windows: No library "jawt" (linux: libjawt.so, win32: jawt.dll) is NOT found ! They do exist in jre/bin. Workaround: Add <java-home-dir>/jre/bin to your PATH environment variable ! Well, this version improves the multithreading behavior a lot. I have attached the last CHANGES.txt changes ;-) here ! Thoughts & Ideas are wellcome ! Last but not least: You can get the test release here: binary-packages: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/binpkg sources, doc's, demo's: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/archive The CVS repository is commited and tagged: rev-2-5-2-0-test1 Yours, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6iM90HdOA30NoFAARApPWAKCuZlUklyFlxY4DJzO8wtpiiqj4hgCgizvV hq8htuSHTGJHFYfk4rQ4awE= =+QDi -----END PGP SIGNATURE----- |
|
From: Thorsten R. <ro...@iv...> - 2001-02-12 14:07:08
|
Hi *,
I thought the following code fragment would fill the window with well
defined alpha values, why not ?
=== 8< ===
gl.glClearColor (0f, 0f, 0f, alpha);
gl.glColorMask (false, false, false, true);
gl.glClear (GLFunc.GL_COLOR_BUFFER_BIT);
=== 8< ===
But when I'm also "unlocking" any of the r,g,b-parts in glClearColor,
than it works! why ?
ciao, Thorsten
|
|
From: Sven G. <sgo...@ja...> - 2001-02-11 03:46:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 08 February 2001 10:42, you wrote: > > I had some problems porting some code to GL4Java. Specifically, > > in order to get animation working at all and with good > > performance, it was necessary to subclass GLAnimCanvas and use > > the following settings: > > setUseRepaint(true); > > setUseFpsSleep(false); > > setSuspended(false); > > > > I found that calling sDisplay() in my main thread reliably > > crashed the machine (apparently doing something relating to > > multithreaded access to the OpenGL context the GeForce didn't > > like). > I have checked this bug out while playing around with the glDemosCvs ! I just pressed the repaint:=false & fpsSleep=false buttons ! Also I have changed the GLLandscape Demo: - added those buttons - added two more threads, which just makecurrent/Free and reads some GL strings without any pause ! Well, the specification of glXMakeCurrent says, that if another threads uses the GLXContext, glXMakeCurrent should fail, so gljMakeCurrent will fail and the display method finishes ! I have played arround with an own manual java-thread locking (monitor) mechanism within gljMakeCurrent/gljFree ! So this looks like a missbehavior of NVidia's glXMakeCurrent (X11 driver for Linux) implementation -> not thread safe !? With the new java monitor for within gljMakeCurrent/gljFree the responsiveness and reliabel rised: - no more mouse-click -> openGL loss (thread is now waiting) - with a kind of tri-state, better java-thread switching .. I have also added in gl4java.applet.SimpleAnimApplet1 a feature for mouse button 3, where (if pressed), the GLCanvas is moved to a new Frame. Pressed again, it is moved back ;-) It works, I have just added a glj = null, in the cvsDispose method .. well looks more stable now .. (tested with above described demos) but it is an NVidia - X11 driver implementation problem ! Not happend within NVidia - Win32 and the DRI XFree86 drivers ! later, sven - - - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 - - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6hLdZHdOA30NoFAARAowsAJ4r1Kgg6qTax/XVwergv6nyec8MuQCfQPSu Sn1qBrCE0OBKPTFA4oDU2TY= =67RA - - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6hS9NHdOA30NoFAARAnXdAJ9th+udycrJ5xWhQIGdXtMWf6oH7ACfeX65 p4a0tnBvYw4uXpSGjW4HeQw= =VgWM - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6hgsdHdOA30NoFAARAoEXAJ0RE1cx6W577JxrUVEwNX6v7oEHhQCgv8aj iRtyzL32zHughNFLXc7liG8= =MFmT -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-09 03:36:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 08 February 2001 22:31, you wrote: > Hi, > > I had a demo running well, using GLAnimCanvas. I can't keep this class > because it is a heavyweight class and I have to use it with lightweight > classes, making it appear always on top of them. I replaced GLAnimCanvas > with GLAnimJPanel and now opengl seems to be not accelerated and uses 100% > of CPU. What happens ? > > Thanks for your help > > Nicolas Cadilhac GLAnimJPanel runs at lightweight either .. but not for the cpu :)) Well, it uses offscreen rendering, where hardware acceleration is usually not supported by the graphic cards OpenGL driver ! But my be with jdk1.4 and/or glx-pbuffers (X11, Win32: ??), a bit more acceleration (if not true hw acceleration) can be done. The problem is, that there is no true hw display for a lightweight window. So currently the OpenGL rendering is done offscreen and copied into the lightweight window, using GLU. I know .. very bad ! Ideas ? sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6g2WvHdOA30NoFAARAtsaAKC7ICMyRwgcjJc/7a+qIva+MXsXEgCeIE71 Y4Un7MMaT1E07g73hwVzZH0= =iApD -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-09 03:14:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you are interesting in, please join the discussion in the "gl4java-development" mailinglist. It is about the performance and thread-safety implementation of GL4Java. E.g.: the need for gljMakeCurrent/gljFree encapsulated gl-calls in the display method ! thanxs sven - ---------- Forwarded Message ---------- Subject: Re: [Gl4java-development] problems with gljMakeCurrent/gljFree Date: Fri, 9 Feb 2001 04:07:21 +0100 From: Sven Goethel <sgo...@ja...> To: gl4...@li... - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, well I have: linux-2.4.1 + i686, XFree86 4.0.2 + GeForce256 +nvidia 0.96-nda-binary-driver (at 32bpp) .X.err: ===== (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients ... (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7758 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7757 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients ... ! no exception ! The problem - you are right - is the call of the gljFree() method, which calls glXMakeCurrent( (Display *)disp, None, NULL ) to free the GLXContext ! The NVidia driver makes a stderr printout of the context numbers .. The reason is, that if you have bound one GLXContext to one thread, and another thread wants to use it, it will fail. There can be only one current GLX context per thread. The reason in the demo's and for the advice to encapsulate your frame renderings within gljMakeCurrent/gljFree is to make the GLX context avaiable for possible other threads. This is more safe. Well, I do not know why the NVidia driver is that verbose :-). The OpenGL manual says, that a call of MakeCurrent should not be very time consuming ! The implementation of gljMakeCurrent only changes the GLXContext, if the current GLXContext is not the one we want to make current ! I have just testet with gears.java (>java gears -perftest): With gljFree() call in end of display method: loading libs(gl, glu): null, null: true useFpsSleep: false useRepaint: false GL VERSION : 1.2.1 GL RENDERER: GeForce 256/AGP/SSE GL VENDOR : NVIDIA Corporation 280 frames in 5.005 seconds = 55.94405594405595 FPS 670 frames in 5.001 seconds = 133.9732053589282 FPS 656 frames in 5.006 seconds = 131.0427487015581 FPS 607 frames in 5.005 seconds = 121.27872127872128 FPS 587 frames in 5.008 seconds = 117.21246006389777 FPS Without gljFree() call in end of display method: loading libs(gl, glu): null, null: true useFpsSleep: false useRepaint: false GL VERSION : 1.2.1 GL RENDERER: GeForce 256/AGP/SSE GL VENDOR : NVIDIA Corporation 3491 frames in 5.0 seconds = 698.2 FPS 4945 frames in 5.0 seconds = 989.0 FPS 4973 frames in 5.0 seconds = 994.6 FPS 4940 frames in 5.0 seconds = 988.0 FPS 4919 frames in 5.001 seconds = 983.6032793441311 FPS 4903 frames in 5.0 seconds = 980.6 FPS 4944 frames in 5.0 seconds = 988.8 FPS Well, this looks like a need to think things over ! This is a performance task and a call for thinking the thread-safe mechanism over ! Ideas ? sven On Friday 09 February 2001 01:35, you wrote: > Hi *, > > here comes rather a feedback than a question... Have fun with my bad > english... 8-) > (I hope it's not off-topic) >(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients > I wonder if somebody else has the same problems: > > I've wrote a tiny test-application, doing nothing but "swapping" front and > back buffer. > (ok, copying back to front buffer via "gljSwap()" - have a look at the > attachment) > > I've got the following log: > > === schnipp === > > [...<java emptyLoop_GLCanvas>...] > > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 0 > clients > (II) NVIDIA(0): purgeCache: Free=0x198f000 Total=0x1fd0000 > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 1 drawables, 1 > clients > emptyLoop_canvas.init > emptyLoop_canvas.reshape > ..(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 2 drawables, 1 > clients > .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3 drawables, 1 > clients > .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 4 drawables, 1 > clients > > [...<counting "drawables" 5-3888> ...] > > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3889 drawables, 1 > clients > # # An unexpected exception has been detected in native code outside the > VM.# Program counter=0x48c3cf8c > # > # Problematic Thread: prio=5 tid=0x81f1498 nid=0x581 runnable > # > Aborted > [thr@elite thr]$ (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, > 3888 drawables, 1 clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > > [...<last line repeats ~20 times> ...] > [...<auto re-init of X/nvidia-driver> ...] > > === schnipp === > > Configuration: > > PC > - AMD Athlon 600MHz > - Asus K7M Mainboard > - 256MB Ram > - Asus GeForce2 32MB V7700 > - SBLive Player 1024 > > Linux Red Hat 7.0 > - XFree 4.01 > - Gnome (default version on redhat 7.0) > - KDE (default version on redhat 7.0) > > OpenGL > - gl4java 2.5.0.0 > - nVidia Drivers 0.94 - 0.96 > > also tried > - Kernel 2.2.18 > - kde 2.01 > - no window manager at all > > So I wrote a tiny "GLAnimCanvas" class for my own. As a result there is no > need to call "gljMakeCurrent()" and "gljFree()" in the display() method > anymore (both are called only once at initialization time). Via a > SwingUtilities like method "invokeLater" and "invokeAndWait" other Threads > are able to use OpenGL commands getting executed in the main Render-Thread. > Now no more crashes after two days of running tests. Then I studied the > differences between the class implementations. > > My thesis: It look's like something (i.e. the nvidia driver, X, or > whatever) doesn't "like" the gljMakeCurrent()/gljFree() combination called > to often. What is the reason having to call both methods in > GLAnimCanvas.display() every frame? > > Any comments ? > [ ] what a hero! ;-) > [ ] nice to know > [ ] what a pain to read > [ ] text to long > [ ] never send attachments > [ ] just get away > > ciao, Thorsten - - ---------------------------------------- Content-Type: application/octet-stream; charset="iso-8859-1"; name="emptyLoop_GLCanvas.java" Content-Transfer-Encoding: quoted-printable Content-Description: - - ---------------------------------------- - - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6g17rHdOA30NoFAARAnG2AKCykVtWJdRe+wwuYlG8cuBnlpgx1wCgiPNZ 2apDQPgaBYGFrRB+Cs6wlxA= =mQed - -----END PGP SIGNATURE----- _______________________________________________ Gl4java-development mailing list Gl4...@li... http://lists.sourceforge.net/lists/listinfo/gl4java-development - ------------------------------------------------------- - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6g2BnHdOA30NoFAARAuXXAJwP8fDdirLAjNggWokllgga3+IndgCgk8ez sbthD0WMFiI6C4wPkZzGQKY= =mz59 -----END PGP SIGNATURE----- |
|
From: Thorsten R. <ni...@gm...> - 2001-02-09 00:52:47
|
Hi again, just a simple question: Does somebody know how to render two quads with the same coords values _without_ gfx issues? Dependant on camera position both quads will intersect each other in "small triangles" (some fragments are drawn from the first quad, other parts from the second). I have to enable GL_DEPTH_TEST by other reasons. I've found something about a glPolygonOffset() but I don't understand the docu. After (trial and error) playing with the arguments it works when the quads lies parallel to the x- and y-axis. But when rotating ... Also glDepthFunc(GL_LEQUAL) doesn't solve the problem. Any ideas ? Is it too easy ? Please give me a hint ... ciao, Thorsten |
|
From: Nicolas C. <cad...@mi...> - 2001-02-08 21:24:24
|
Hi, I had a demo running well, using GLAnimCanvas. I can't keep this class = because it is a heavyweight class and I have to use it with lightweight = classes, making it appear always on top of them. I replaced GLAnimCanvas with GLAnimJPanel and now opengl seems to be not = accelerated and uses 100% of CPU. What happens ? Thanks for your help Nicolas Cadilhac |
|
From: Sven G. <sgo...@ja...> - 2001-02-08 09:43:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 08 February 2001 09:52, you wrote: > > experiences with: > > > > XFree86 4.0.2, GL4Java 2.5.0, KDE2.1b2 + konqueror 2.1b2 and > > - jdk1.2-sun: no display .. > > - jdk1.3-sun: no display .. > > > > - jdk1.3-IBM: runs well > > ================== > > I've been running GL4Java on top of Sun's JDK 1.3 on Windows 2000 > successfully with an NVidia GeForce. > well, me either, but thats OT :-) > I had some problems porting some code to GL4Java. Specifically, > in order to get animation working at all and with good > performance, it was necessary to subclass GLAnimCanvas and use > the following settings: > setUseRepaint(true); > setUseFpsSleep(false); > setSuspended(false); > > I found that calling sDisplay() in my main thread reliably > crashed the machine (apparently doing something relating to > multithreaded access to the OpenGL context the GeForce didn't > like). Well for all the demos where I tried those flags, a crash never happend. So please send a little nice example (tar.bz2 or zip). Be sure to free and makeCurrent the GLContext, especially in a multithreading application ! I am thinking about a more precise native animation sheduler for a next version. So the fps can be more accurate. "Artiste on the Web" told me success with the yield() method, to allow other threads being run. Anyway, todays JVM's implements the native threading very well. The rest of the posting is something I do not understand, because it uses word's outta my universe ;-)) Well, I appreciate to make GL4Java more stable and better. I does not love a magician shoe - no i do not, but the world is a free one, at least the GNU world. I would prefere an own free solution for a common API. bye, sven > > I should note that I played a little bit with the non-free > Magician binding and believe that there are some unresolved > issues with GL4Java's interaction with the window system. > Specifically, a friend and I did an experimental project in which > we shoehorned some of GL4Java's sources into the Magician > APIs. Unfortunately, it wasn't stable (crashed frequently on his > machine), likely due to my inexperience with the multithreading > issues in interacting properly with the AWT. However, performance > of this system appeared to be significantly better than my first > attempts with GL4Java, probably because we were able to avoid the > repaint() mechanism and associated thread synchronization. > > I'm planning on doing some more work on this over the next few > weekends -- if anybody has experiences to share or would like to > collaborate please send mail. > > -Ken > > > ___________________________________________________________________________ >__ Kenneth B. Russell (kbr...@al...) > http://www.media.mit.edu/~kbrussel > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > http://lists.sourceforge.net/lists/listinfo/gl4java-usergroup - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6gmoOHdOA30NoFAARAv26AKCl7bW89ZcRwcsyNvkq1XyjKXFOawCgoQhl ruji1jrgN9jncbE2HQi+RLE= =Lz3U -----END PGP SIGNATURE----- |
787 messages has been excluded from this view by a project administrator.
