gl4java-usergroup

Re: [gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

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

On Sunday 16 December 2001 09:08, Kenneth B. Russell wrote:
> > On Sunday 16 December 2001 05:22, Sven Goethel wrote:
> > > and if GLContext does now the requesting object,
> >
> > may i should not do this work, while i am drunken ?
>
> Not doing this work while drunk sounds like an excellent idea.

i am thinking about it

but this idea has also its pitfalls.

assuming that you have a smaller resistance 
to do special kinda work which must be done.

assuming that even the drunken work is proven by a compiler and a test 
program (well the syntax checker for the comentaries is not yet mentioned here ;).

assuming that having fun with coding can be enhanced 
while shutting down some neurons with the generous help of alcohol.

working on a program which purpose never was to beat the human "intelligence",
but with the help of this fine bottles of rum,
well, this program allready has beaten you .. hicks...

;-)

FOR ALL THAT CHILDREN AND NON-JOKERS:
	
	stop drink, before you cannot think anymore


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

iD8DBQE8HK+4HdOA30NoFAARAsf4AJ43KlSdFc3+XGaYKCpJxYFgVL5tzACcCt5b
tDx2JwhoDPeVmhWBiID8Cm4=
=1KCo
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

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

On Sunday 16 December 2001 05:22, Sven Goethel wrote:
> and if GLContext does now the requesting object,

may i should not do this work, while i am drunken ?

;-)

till tomorrow .. bye, sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8HC21HdOA30NoFAARAnulAJ9N5MaU3+oPxcJwoQYahrHIM0zzagCfaFOj
YiQls2J6NpAAzyMzFqenMgw=
=K9dW
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

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

On Sunday 16 December 2001 05:06, Sven Goethel wrote:
>
> so i reduced the calls for this function (to null), hopefully
> without a loss of performance .. (i guess so, till we keep track
> of the GL context allready ;-) ..

sorry .., i meant: _since_ we kept track of the GL context allready !

our automatic GL context switcher within GLContext,
does respect the past, the future and the capabilities of the object ..

so it only does a true "makeCurrent" and "free", if it is needed,
and if GLContext does now the requesting object,
e.g. if it is an instanceof GLRunnable ..

later, sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8HCGQHdOA30NoFAARAk1lAJ0c7Z6UHnlPiAj8qa2flP2UmYxgbgCfVUBF
dVDuZN+pDDxdtsxAna1GjyA=
=flSw
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

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

On Sunday 16 December 2001 04:59, Sven Goethel wrote:
>
> (btw: there is no more "enableAWTThreadRendering" ;-)

oh .. bullshit ..

look like i missed to control this issue ;-)

ok, it is still in there .. 

even i do not like it ;-),
i won't change it, cause it looks like a working workaround ;-)
for some reasons ..
(yep, kbr explained it .. a lack in NVidia's mutlithreading functionality)

> there is no limitation to use "glXGetCurrentContext" !

officially not - right ..

well, may be she has (the company) has introduced another bug ..

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

iD8DBQE8HB+0HdOA30NoFAARAlOMAJsGXJPBrQQOm2vjco97ZbBQ/BCdbgCgq5lN
SjWIjc2Y1o9M2o1bPxpVDto=
=ku0h
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

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

On Saturday 15 December 2001 21:23, Sven Goethel wrote:
> dear users,
>
> i have unsuccesfully tried
> linux 2.4.16 + NVidia's new 2314 driver ..
>
> (with NVidia's 1541, everything is fine)
>
> the problem is, that i get the following error,
> while running e.g. "java morph3d":
>
> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : 11 occurred at PC=0x4aac5358
> Function name=glXGetCurrentContext
> Library=/usr/X11R6/lib/libGL.so
>
> Current Java thread:
>         at gl4java.GLContext.gljMakeCurrentNative(Native Method)
>         at gl4java.GLContext.gljMakeCurrent(GLContext.java:2472)
>         at gl4java.awt.GLCanvas.sDisplay(GLCanvas.java:697)
>         at gl4java.awt.GLAnimCanvas.run(GLAnimCanvas.java:466)
>         at java.lang.Thread.run(Thread.java:484)
>
> the pure native "morph3d" and "gears" runs very well ..
>
> any idea ?
>

well, i have checked some circumstances ..

to kbr: it has nothing todo with multithreading,
regarding the specification of the "glXGetCurrentContext" function !

for "some" cases, 
the call of NVidia's 2314 driver's "glXGetCurrentContext" 
produces an signal 11 ..

so i reduced the calls for this function (to null), hopefully
without a loss of performance .. (i guess so, till we keep track 
of the GL context allready ;-) ..

i truly believe this is a bug by NVidia, so 
somebody may contact them ..

i have tagged this code, search for "JAU NVidia 2314 Bug"
within
	CNativeCode/OpenGL_X11_jawt.c
	CNativeCode/OpenGL_X11.c
	gl4java/GLContext.java.skel

i do have checked this code pieces in allready ..
	
this tagged code is just temporary within CVS, 
'cause we do not want to add workarounds for closed source vendor bugs ..

later, we may remove these workarounds ..

so for all non CVS people, please use NVidia's driver 1541,
till the successor (bugfix) of 2431 is made by NVidia !!

> 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

iD8DBQE8HB3LHdOA30NoFAARApouAKCDTFDfinAWVWyoJHAyUDEOqOxIPQCeL+U8
yLZlkS+xuTHoSYwWdjvZf14=
=3PND
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

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

On Sunday 16 December 2001 04:34, Kenneth B. Russell wrote:
> > An unexpected exception has been detected in native code outside the VM.
> > Unexpected Signal : 11 occurred at PC=0x4aac5358
> > Function name=glXGetCurrentContext
> > Library=/usr/X11R6/lib/libGL.so
> >
> > Current Java thread:
> >         at gl4java.GLContext.gljMakeCurrentNative(Native Method)
> >         at gl4java.GLContext.gljMakeCurrent(GLContext.java:2472)
> >         at gl4java.awt.GLCanvas.sDisplay(GLCanvas.java:697)
> >         at gl4java.awt.GLAnimCanvas.run(GLAnimCanvas.java:466)
> >         at java.lang.Thread.run(Thread.java:484)
>
> Try changing the demos to use the GLEventListener model (if they
> aren't already) and setUseRepaint(false) on the GLAnimCanvas.
> This should prevent multithreaded use of the OpenGL context via
> the internal "enableAWTThreadRendering" flag. If this fixes the
> crash, there is either a bug in NVidia's drivers with respect to
> multithreading or there is a threading bug in GL4Java. NVidia
> employees tend to frequent the OpenGL discussion forums:
>
> http://www.opengl.org/discussion_boards/cgi_directory/Ultimate.cgi

dear kenneth,

there is no bug in gl4java - for sure ;-)

because there is no limitation to use "glXGetCurrentContext" !

(btw: there is no more "enableAWTThreadRendering" ;-)

i do now collect the calls of "glXGetCurrentContext"
and do comment them out temporarey, till NVidia has bugfixed their
release ..

there are also some more offscreen renderer bugs within NVidia's driver,
i do _not_ workaround now .. (in a lack of interest)

well, i am also not interesting in doing much workaround work
for their drivers and their bugs .. so i just do a checkin in 
some minutes .. and we may see what happens ..

but, of course, thanxs a lot for your attention ..

later, sven

- -- 
health & wealth
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440 ; fax : +49-521-2399442
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8HBwKHdOA30NoFAARAk4IAKC7TLMmwjCm/oH5NbvEUw6EOA4wigCeKN2F
o6fjd/UV+IaVNfneQsJ0Lvc=
=efih
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : 11 occurred at PC=0x4aac5358
> Function name=glXGetCurrentContext
> Library=/usr/X11R6/lib/libGL.so
> 
> Current Java thread:
>         at gl4java.GLContext.gljMakeCurrentNative(Native Method)
>         at gl4java.GLContext.gljMakeCurrent(GLContext.java:2472)
>         at gl4java.awt.GLCanvas.sDisplay(GLCanvas.java:697)
>         at gl4java.awt.GLAnimCanvas.run(GLAnimCanvas.java:466)
>         at java.lang.Thread.run(Thread.java:484)

Try changing the demos to use the GLEventListener model (if they
aren't already) and setUseRepaint(false) on the GLAnimCanvas.
This should prevent multithreaded use of the OpenGL context via
the internal "enableAWTThreadRendering" flag. If this fixes the
crash, there is either a bug in NVidia's drivers with respect to
multithreading or there is a threading bug in GL4Java. NVidia
employees tend to frequent the OpenGL discussion forums:

http://www.opengl.org/discussion_boards/cgi_directory/Ultimate.cgi

[gl4java-usergroup] gl4java + nvidia 2314 (GeForce256)

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

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

dear users,

i have unsuccesfully tried 
linux 2.4.16 + NVidia's new 2314 driver ..

(with NVidia's 1541, everything is fine)

the problem is, that i get the following error,
while running e.g. "java morph3d":

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4aac5358
Function name=glXGetCurrentContext
Library=/usr/X11R6/lib/libGL.so

Current Java thread:
        at gl4java.GLContext.gljMakeCurrentNative(Native Method)
        at gl4java.GLContext.gljMakeCurrent(GLContext.java:2472)
        at gl4java.awt.GLCanvas.sDisplay(GLCanvas.java:697)
        at gl4java.awt.GLAnimCanvas.run(GLAnimCanvas.java:466)
        at java.lang.Thread.run(Thread.java:484)

the pure native "morph3d" and "gears" runs very well ..

any idea ?

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

iD8DBQE8G7FMHdOA30NoFAARAsX9AJ97/Gowk614RHZp7cTX88Q4i5UutQCZAQ8M
8CAiOTv0Ov1lPk6FEyyKk58=
=7afF
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] DEPTH BUFFER

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

> How can I change the number of bits of the depth buffer.
> I have used:
> GLContext kj =this.getGLContext();
> GLCapabilities lk = kj.getGLCapabilities();
> lk.setDepthBits(32);

This definitely won't work; you need to set this before you
create the context. For example, use the GLDrawableFactory and
set up the GLCapabilities when you call createGLAnimCanvas.
However, I'm not sure what depth buffer sizes most current
hardware supports. I think the GLDrawableFactory will return null
if the requested depth can't be satisfied, but am not sure.

[gl4java-usergroup] DEPTH BUFFER

[Ricardo <ro...@gl...>]

How can I change the number of bits of the depth buffer.
I have used:
GLContext kj =this.getGLContext();
GLCapabilities lk = kj.getGLCapabilities();
lk.setDepthBits(32);

in the init function, but don't work, I have a large terrain scene, and the
z-buffer don't work properly with vertex, the depth buffer has 16 bits, if I
can put 32 or 64, the problem will solve, I think

Thanks

[gl4java-usergroup] FAQ-ADD: How-To Complain About Non Working GL4Java ?

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

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

1.) Write an email to this mailingist !
2.)  Add the following informations:
	- OS Vendor & Version
	- The output of: "java gl4java.GLContext -infotxt"
	within a zip'ed od bzip2'ed file !

3.) Be polite ;-)
4.) Be patient ;-)

5.) If you feel, that the above GL4Java self-test info is correct,
please add the output of the demo/MiscDemos/gears.java demo,
within a compressed file also (zip or bzip2).

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

iD8DBQE8FolBHdOA30NoFAARAsmoAJ4klnHd35JbG4RorhZa/xp8kz2PHgCgoeTI
XzXCA5+sSJBSzVP4XqluEXU=
=UtXh
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] Recieving: java.lang.UnsatisfiedLinkError: gljFetchGLFunctions on 2.8.2 build

[Frank A N. <tn...@ju...>]

>>         I am running GL4Java on a Windows 2000 machine.  I also got
the
>> same results on 2.8.1, how not on 2.7.x.  I used both manual and the
>> Install program to install.  As you can see I am using JDK 1.3 (java
full
>> version "1.3.0-C").  Anyone else getting this?
>> 
>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
>> gljFetchGLFunctions
>>         at gl4java.GLContext.gljFetchGLFunctions(Native Method)
>>         at gl4java.GLContext.doLoadNativeLibraries(GLContext.java:893)
 
>gljFetchGLFunctions was recently changed from a native method to
>a Java method and the native method renamed to
>gljFetchGLFunctions0. It looks like an old version of gl4java.jar
>is being used with the new native library. I haven't tested the
>Win2k binaries from the website but the code in the source tree
>works.

Thanks Kenneth for the insight.  When ended up happening is I have more
then one JDK installed on my machine and was using an old set of jar file
with a new set of DLLs.  Also, it fix my problem earlier with getting the
"problem in use() method" when using GLJPanels.

Thanks again

Tony
 
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.

Re: [gl4java-usergroup] Recieving: java.lang.UnsatisfiedLinkError: gljFetchGLFunctions on 2.8.2 build

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

>         I am running GL4Java on a Windows 2000 machine.  I also got the
> same results on 2.8.1, how not on 2.7.x.  I used both manual and the
> Install program to install.  As you can see I am using JDK 1.3 (java full
> version "1.3.0-C").  Anyone else getting this?
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> gljFetchGLFunctions
>         at gl4java.GLContext.gljFetchGLFunctions(Native Method)
>         at gl4java.GLContext.doLoadNativeLibraries(GLContext.java:893)

gljFetchGLFunctions was recently changed from a native method to
a Java method and the native method renamed to
gljFetchGLFunctions0. It looks like an old version of gl4java.jar
is being used with the new native library. I haven't tested the
Win2k binaries from the website but the code in the source tree
works.

[gl4java-usergroup] Recieving: java.lang.UnsatisfiedLinkError: gljFetchGLFunctions on 2.8.2 build

[Frank A N. <tn...@ju...>]

To All,
        I am running GL4Java on a Windows 2000 machine.  I also got the
same results on 2.8.1, how not on 2.7.x.  I used both manual and the
Install program to install.  As you can see I am using JDK 1.3 (java full
version "1.3.0-C").  Anyone else getting this?

F:\GL4Java\demos\GL4Java\demos\SwingDemos>java InternalGLFrameDemo1
GLContext.loadNativeLibraries will do it !
jvm vendor: Sun Microsystems Inc.
jvm version: 1.3.0
jvm version (parsed): major: 1, minor: 3
loaded native library: GL4JavaJauGljJNI13
fetching GL/GLU functions ...
Exception in thread "main" java.lang.UnsatisfiedLinkError:
gljFetchGLFunctions
        at gl4java.GLContext.gljFetchGLFunctions(Native Method)
        at gl4java.GLContext.doLoadNativeLibraries(GLContext.java:893)
        at gl4java.GLContext.loadNativeLibraries(GLContext.java:581)
        at gl4java.swing.GLJPanel.<clinit>(GLJPanel.java:178)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:120)
        at
InternalGLFrameDemo1$InternalGLFrame.switchGLJPanel(InternalGLFrameDemo1.
java:141)
        at
InternalGLFrameDemo1$InternalGLFrame.<init>(InternalGLFrameDemo1.java:116
)
        at InternalGLFrameDemo1.createFrame(InternalGLFrameDemo1.java:59)
        at InternalGLFrameDemo1.<init>(InternalGLFrameDemo1.java:32)
        at InternalGLFrameDemo1.main(InternalGLFrameDemo1.java:70)
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.

Re: [gl4java-usergroup] GLJPanel bug?

[Toshiyuki I. <is...@mi...>]

Thanks for your reply.

----- Original Message -----
From: <NM...@th...>
Sent: Tuesday, December 11, 2001 5:30 AM

> Hi,
>
> Regarding your first issue...
>
> Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " .
>
> For some reason the GLCanvas uses the left hand rule and the GLJPanel is
> using the right hand rule. So when drawing scenes get kind of turned
> around.  I don't know whether this is documented anywhere, but I think it
> should be added if it isn't. Or the "quirk" should maybe be looked at
being
> corrected so the two components are consistent.
>
I'm try to call 'gl.glTranslatef(0.0f,-1.0f,0.0f) ' in display() 
after initialize MODELVIEW matrix.
However, my Panel still shows the reverse view.
Sorry, I can't understand why calling glTranslate function.

> As for your second issue, sorry, I am unable to help you out.
>
> Hope that helps,
> Noah
>

--
Toshiyuki Ishimura

Re: [gl4java-usergroup] GLJPanel bug?

[Toshiyuki I. <is...@mi...>]

Thanks for your reply.

----- Original Message -----
From: "Sven Goethel" <sgo...@ja...>
Sent: Tuesday, December 11, 2001 11:24 AM


> On Tuesday 11 December 2001 02:44, Sven Goethel wrote:
> > On Monday 10 December 2001 21:30, NM...@th... wrote:
> > > Hi,
> > >
> > > Regarding your first issue...
> > >
> > > Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " .
> >
> > the upside-down problem will be solved with this trick,
> > without any big performance lost ..
> >
> > so, i might should add this to the class into the init method ..
> >
> > if nobody complains (please vote), i will do so !
> >
> > i guess this is much faster, than the java image transformation ;-)
> >
> > thanxs to Noah
> >
>
> oops .. i guess i was to fast ..
>
> this is not a general purpose solution,
> a glRotatef neither ..
>
As my reply to Noah, I can't understand calling glTranslate.
Please tell me its meaning.
Here, I try to call 'gl.glScalef(1.0f, -1.0f, 1.0f)' after
initialize MODELVIEW matrix.
Then, the Panel shows the correct view without turning upside down.

> a general purpose solution would be, like Toshiyuki's one,
> but i am afraid that this one is a big performance lost ..
> even if it works nice !
>
> so, we must live with it, and the application should take care about it,
> or we better need a general purpose gl solution ..
>
> please send your ideas ..
>

I think so.
If any document about this problem (upside-down problem) is available,
maybe I didn't comfuse.
I wish to give some attension about this to users in FAQ, manual or API doc.

Regards,

--
Toshiyuki Ishimura

Re: [gl4java-usergroup] GLJPanel bug?

[Toshiyuki I. <is...@mi...>]

Thanks for your reply.

----- Original Message -----
From: "Kenneth B. Russell" <kbr...@al...>
Sent: Tuesday, December 11, 2001 2:09 PM


>
> > Also, I wish to speed up the GLJPanel with new API in JDK1.4
> > (e.g. the VolatileImage class and the java.nio package).
> > GL4Java developers have any plan at this point?
>
> I think the way to get more speed out of GLJPanel is to avoid the
> pixel copy that is occurring now, by keeping track of where the
> GLJPanel is within the component hierarchy, clipping the OpenGL
> rendering region appropriately, and drawing directly to the
> heavyweight component to take advantage of hardware acceleration.
> This won't work if the component is partially occluded, but that
> rarely happens and the system could revert back to the current
> pixel copy in that case.
>
I think so that copying pixel data slows down GLJPanel.
I think that 'direct buffer' in JDK1.4 such as NVidia's support in gl4java
may possibly improve this problem.
However, I don't have knowledge about new io package.

> I'm pretty sure this technique was used in the now-defunct
> Magician Java binding for OpenGL and is discussed in the author's
> book:
>
> http://www.symbolstone.org/technology/java/nmbook/
>
I will visit this site.

By using gl4java, we can built big and complex applications
without depending on several GUI libraries.
I think that this point is one of big advantages of gl4java.
In fact, I am making a map application, which has many swing component.
Maybe speeding up GLJPanel as Java lightweight component expand
possibility of application development (e.g. MDI application with GL
rendering).
From these, I think that improvement of GLJPanel perfomance is important.
So, I want to imporve it, but I have no idea.

Regards,

--
Toshiyuki Ishimura

Re: [gl4java-usergroup] GL4Java 2.8.2 ReleaseCandidat 1 (2.8.2.0) !

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

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

On Tuesday 11 December 2001 08:51, Sven Goethel wrote:
> please use the mailinglist for responses - thanxs
>
> http://www.jausoft.com/gl4java/
> http://sourceforge.net/projects/gl4java
>
> live long & prosper
>
> sven

you might want to check out the solaris binaries
for sparc and x86,
made by kenneth b. russel !

if you solaris users don't mind, 
please check out the installer via solaris also - thx.

last but not least, 
i bugfixed the installer a bit ..

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

iD8DBQE8FbyiHdOA30NoFAARAoeTAKCmPaTHychsxdEIOb31hFzjg6mjwQCeLXYf
aGG93swY8HKgrViPRcN+jhE=
=dEIN
-----END PGP SIGNATURE-----

[gl4java-usergroup] GL4Java 2.8.2 ReleaseCandidat 1 (2.8.2.0) !

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

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


please use the mailinglist for responses - thanxs

http://www.jausoft.com/gl4java/
http://sourceforge.net/projects/gl4java

live long & prosper

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

iD8DBQE8FbrrHdOA30NoFAARAvxsAJ9LNxZlNHx4s9Mfn9TdCyCQozYtggCcD2dJ
Ts3gIyfxpP4vj418Q1Pv3vE=
=VQWT
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] GLJPanel bug?

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

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

On Tuesday 11 December 2001 06:09, Kenneth B. Russell wrote:
>
> I think the way to get more speed out of GLJPanel is to avoid the
> pixel copy that is occurring now, by keeping track of where the
> GLJPanel is within the component hierarchy, clipping the OpenGL
> rendering region appropriately, and drawing directly to the
> heavyweight component to take advantage of hardware acceleration.
> This won't work if the component is partially occluded, but that
> rarely happens and the system could revert back to the current
> pixel copy in that case.
>
> I'm pretty sure this technique was used in the now-defunct
> Magician Java binding for OpenGL and is discussed in the author's
> book:
>
> http://www.symbolstone.org/technology/java/nmbook/
>

anybody intersting in implementing such a nice thing ?

or should we just use the solution of a native awt component ?
(allready discussed ..)

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

iD8DBQE8FZo5HdOA30NoFAARAt6+AJwO8xH0c2hG2pbqnE9qk+GZRIX1YgCgnOWS
uLHkfHoJaNQQekpm6wNyvp8=
=+JOF
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] GLJPanel bug?

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

> Also, I wish to speed up the GLJPanel with new API in JDK1.4
> (e.g. the VolatileImage class and the java.nio package).
> GL4Java developers have any plan at this point?

I think the way to get more speed out of GLJPanel is to avoid the
pixel copy that is occurring now, by keeping track of where the
GLJPanel is within the component hierarchy, clipping the OpenGL
rendering region appropriately, and drawing directly to the
heavyweight component to take advantage of hardware acceleration.
This won't work if the component is partially occluded, but that
rarely happens and the system could revert back to the current
pixel copy in that case.

I'm pretty sure this technique was used in the now-defunct
Magician Java binding for OpenGL and is discussed in the author's
book:

http://www.symbolstone.org/technology/java/nmbook/

Re: [gl4java-usergroup] Newbie GLJPanel and GLAnimJPanel

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

>         I am just trying to how the GLJPanel and GLAnimJPanel works.  I
> (like other posts, with no clear answer) am getting 
> GLJPanel: problem in use() method message went executing a GL4Java
> program using a GLJPanel.

Instead of subclassing GLJPanel, try using the new
GLEventListener interface; see e.g., demos/MiscDemos/gears.java
and demos/new-style.txt. This will prevent invariants from
accidentally being broken while subclassing. Follow up if you
still have problems.

Re: [gl4java-usergroup] GLJPanel bug?

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

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

On Tuesday 11 December 2001 02:47, Sven Goethel wrote:
> On Monday 10 December 2001 20:25, Toshiyuki Ishimura / ?? ?? wrote:
>
> > After this modification, I get the same result between
> > the GLCanvas and the GLJPanel.
> > Does this GLJPanel behavior keep GL4Java's specification?
>
> what do you think ? it's not a bug, it's a feature ? ;-)
>
> you are right, but i guess we take Noah's GL transformation
> to the init method .. if nobody complains ..

sorry, i was too quick ..

please read my response to my too quick answer ..

cheers, sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8FW6iHdOA30NoFAARAkgOAJ4pW99nwiH1g0lbXJwpPX+OEiFDwACfQO/g
oi3RcFEolr9C0QrKElU0EE4=
=8GLR
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] GLJPanel bug?

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

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

On Tuesday 11 December 2001 02:44, Sven Goethel wrote:
> On Monday 10 December 2001 21:30, NM...@th... wrote:
> > Hi,
> >
> > Regarding your first issue...
> >
> > Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " .
>
> the upside-down problem will be solved with this trick,
> without any big performance lost ..
>
> so, i might should add this to the class into the init method ..
>
> if nobody complains (please vote), i will do so !
>
> i guess this is much faster, than the java image transformation ;-)
>
> thanxs to Noah
>

oops .. i guess i was to fast ..

this is not a general purpose solution,
a glRotatef neither ..

a general purpose solution would be, like Toshiyuki's one,
but i am afraid that this one is a big performance lost ..
even if it works nice !

so, we must live with it, and the application should take care about it,
or we better need a general purpose gl solution ..

please send your ideas ..

cheers, sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8FW5THdOA30NoFAARAqwXAJwO9HZi3czqXOElGV16BsGE5QAszACeLBuy
fZgE8xdbKt1L2FaFdgVPZVQ=
=V+kO
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] GLJPanel bug?

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

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

On Monday 10 December 2001 20:25, Toshiyuki Ishimura / ?? ?? wrote:
> I have a question and a wish.
>
> I'm making a trial the GLJPanel.
> I declared a Panel class extended from the GLJPanel and
> transplanted from a GLCanvas working correctly to the Panel.
> However, the Panel shows the reverse view every time.

<snip>

> After this modification, I get the same result between
> the GLCanvas and the GLJPanel.
> Does this GLJPanel behavior keep GL4Java's specification?

what do you think ? it's not a bug, it's a feature ? ;-)

you are right, but i guess we take Noah's GL transformation 
to the init method .. if nobody complains ..

>
> Also, I wish to speed up the GLJPanel with new API in JDK1.4
> (e.g. the VolatileImage class and the java.nio package).
> GL4Java developers have any plan at this point?

because not many people currently really use the gl4java.swing
package, it would be nice to have people like you who use it more
in deep, and who is able to make changes.

you are welcome !

>
> I'm sorry about my strange english.
>

what's so strange with it ?

> Regards,

cheers, sven

- -- 
"come on sexy mama, let's kill all humans", bender - futurama
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

iD8DBQE8FWW+HdOA30NoFAARAg9cAJ9sVQ17WkMjcl6IvraI6Wx0KEH8AQCdFQqi
v/mt5sVUyH7kowtOzA+xn9M=
=eeBU
-----END PGP SIGNATURE-----