Menu
▾
▴
Re: [gl4java-development] about Thread and Context
|
From: Artiste on t. W. <a1...@So...> - 2001-02-18 14:55:06
|
Sven Goethel wrote: > On Friday 16 February 2001 18:31, Artiste on the Web wrote: > > Sven Goethel wrote: > > > On Tuesday 19 December 2000 15:38, Artiste on the Web wrote: > > > > Arkanae is a 3D game, developped with Java and GL4Java. > > > > The 0.2.1 version of Arkanae is available here : > > > > http://perso.club-internet.fr/b_lamy > > > > > > > > This new version includes bugfixes, graphic settings, german > > > > translation, and spellcasting with incredible 3D particle system > > > > effects > > > > > > > > :-) > > > > > > > > PS to Sven : In the game, I use by default a the yield() method to > > > > suspend the rendering thread; an option allows to use a sleep(1). > > > > > > > > A11W > > > > > > Dear A11W ;-), > > > > > > i checked out arkanae - it is getting greater and greater, > > > with gl4java 2-5-2-0-test2 prerelease ! > > > > > > well, the rendering acts cool (with a sleep or not), > > > but i got not keyboard action :-( > > > > Yes, i have had the same problem but now it's OK ! > > > > I have forgotten a "gljFree()" after the code that dump the OpenGL > > version/vendor/... (that call "gljMakeCurrent()" before dumping). > > hu .. thanxs, I got into coold sweating .. > > > > i would love to see you testing the new gl4java, > > > to make it more stable .. > > > > Now 2.5.2.0 runs very well. > > But i still get this printed on the console : > > > > GLContext.loadNativeLibraries ... > > GLContext.loadNativeLibraries will do it ! > > > > ??? > > ;-) it is a test release ;-) > i missed this .. I delete it now, thanxs ! > > > > well, i guess the usage of no-repaint with usesleep > > > should be the default for now, it is quiet stable and thread safe. > > > > But what about speed ??? Yield is quickier than sleep, no ? > > > see below .. the quickness of yield is, that YOU USE the > cpu at max .. see below. > > > > the use sleep fps with about 25fps may be importent, > > > if you do not want to give all the cpu power to the renderer ... > > > > Hey !? That's what i want : to give the maximum of the cpu time to the > > 3D ! And only as few as possible for handling events,... > > oh sorry, your eyes are better than mine - or guess what ;-)) ? > > fps - addicted ? > > well, you can not see the difference of a fps 30 - infinitve .., I guess so, > may be it will start just at about 40 fps .. > But why spend all the power of the cpu, just to achieve 100 fps (thats what I got ...). > Just to have a new heating system :-) or spending energy ? > > Well, in the future, you may add some intelligence AI to the enemies, > so theire AI needs cpu either (may be much more than the dumb rendering ..). > > So .. setting a convinent maximum grants you power for other tasks. > Also .. the player may own just one linux-box, > and wants to play the game but wants to compile other things also .. > > So why stealing the cpu power if unneccessary from the global ressources ? > > .. well just my 5 cents :-) > > > Do you kwow about this class : java.lang.ThreadLocal ? > > I've just discovered it today, it is used to create thread-local > > property (=with a different value for each thread). What about making > > the current GL context of a thread a thread-local property ? > > Just an idea... > > because you may want to share the context between NATIVE THREADS ! > > it is about, that the ctx can be used for one native thread at a time ! > > of yourse, you are able to lock the ctx to one thread, > you can do this today, just do not call gljFree() :-), > than nobody else will get this ctx while trying it with MakeCurrent !! > > you allready know these .. (the keyboard - AWT lock, the AWT thread was > set on the waiting state, while requesting the locked - never be freed ctx) ! > > > And maybe a suggestion : don't free the context at the end of display() > > (= after we have done with it) but before another thread use it. So if > > only one thread use the context, it is never freed => speed boost. > > see above: you do not have to call gljFree() ;-), > then nobody will get the ctx ;-) > may be it is about the easy design ... > > the OpenGL definition says, that the implementation of: > glXMakeCurrent(display, drawable, ctx) // our native part of gljMakeCurrent > and > glXMakeCurrent(display, None, NULL) // our native part of gljFree > should not use much ressources (-> cpu) ! > So it must be safe to use it for thread safety ! > > Well, for Win32 and others this MUST be the same ! > > So my Idea: Only call gljFree, if you really want to use OpenGL in one > special thread ! Then just call gljFree() only if this thread is it's creator thread. > The creator thread is the thread who calls init(), usually the AWT thread ! > > The other problem: > One thread can not unlock the ressources (monitor) of another thread > in java, and native (e.g. OpenGL's threads restrictions) ! > > So: How it is is the way it goes .. > > - -- > 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 > > iD8DBQE6jyHzHdOA30NoFAARAr/sAJ0YxuEdOccAev0Fk0P8oIbMvtw2PgCfQ2yv > dIwg77qoKN4tCU8FgsYrSIs= > =F0Ej > -----END PGP SIGNATURE----- |
