gl4java-usergroup

Re: [gl4java-usergroup] interesting speed-up

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

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

On Wednesday 27 March 2002 15:37, Visi G=E1bor wrote:
> Hi,
>
> I've made a little test program using GLAnimCanvas/GLEventListener whic=
h
> just clears the canvas and draws a rectangle. The animate fps is set to
> 5000, and the actual fps is printed after every 50 frames.
> I use jdk 1.4, gl4java 2.8.2.0 and NT4 (ATI RAGE 128 Pro II). When I
> start the app it reports about 130-150 fps. Nothing strange so far...
>
> Now if I start a Media Player (some video), the speed increases to
> 340-360 fps. Could anyone explain me this?
>
> Thx,
> 	Gabor
>

do you do this stuff drunken like me ? ;-)

or is the canvas just not rendered on screen ?

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

iD8DBQE8o0maHdOA30NoFAARAk4SAJ48983eZMENyhHDolutlv7zf5gPWQCgkX/C
YYKSrUk8RWvl47iw6iCn4K8=3D
=3D9+X8
-----END PGP SIGNATURE-----

Re: [gl4java-usergroup] WGL_ARB_pbuffer extension

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

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

On Wednesday 27 March 2002 10:56, Pepijn Van Eeckhoudt wrote:
> Has anyone tried using the WGL_ARB_pbuffer extension to do hw
> accelerated offscreen rendering? Maybe this could be used to get make
> the swing component hw accelerated on win32. If nobody has tried this
> before I'll probably put some time into this...
>
> Pepijn Van Eeckhoudt
>
cool

do it for win32, then i will do it for unix/x11 ;-)

but be sure to query this extension at runtime .. of course.

please test it, and give us some performance comparison

thx a lot

sven


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

iD8DBQE8o0n2HdOA30NoFAARApuZAKCltDSicN/wlEpX18fh13gKJ0fCXwCeMB4X
JYOdUq5Ffv0LvKxjeJFw6XM=
=7lMw
-----END PGP SIGNATURE-----

[gl4java-usergroup] JavaOne / SanFrancisco / etc...

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

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

Hi folks,

we (Kenneth & me) finished out presentation at JavaOne.

people were impressed about the cool demos we had,
indeed JCanyon (Photorealistic Rendering of a huge amount of data set)
and the new Pup Demo (Cartoon Style rendering).

well, if things goes right, the java3d team migth expose opengl 
within their java3d api .. in the future .. sometime .. ;-)

just want to mention it, and not to forget, 
that if you are around the bay area, just gimme a call
415-806-5498, we might can meet each other 8-].
(being online in about 3 hours .., and stay till sunday)

the JavaOne was _and_ still is nice (except the food ;-).

well i am just sitting here at apple in cupertino
in gerards cool room and working on my emails ..

we are thinking about a general purpose higher level
api .. just for fun ;-)

well, i do fix some bugs .. and might add:

- - the J2SE 1.3 tesselation GC stuff by pepeijn
- - more NIO support:
	- correcting some opengl mesa header declaration,
	so more gl stuff can use NIO ..
	- tesselation
	- textures .. (?)
	- ..
- - ... 

see - there is no competition

jau kenneth, i am still sober ;-)
  
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

iD4DBQE8o0j9HdOA30NoFAARAprKAJ9jzCgR4/o8pyhWyyBQUoMQGQnyGwCY3eWd
/nNvYqn+ZQ9BNtZGGYV3wg==
=ynUB
-----END PGP SIGNATURE-----

[gl4java-usergroup] Is there a reason glDrawPixels() is slow on Windows . . . .

[Tobias L. G. <tg...@ul...>]

I am attempting to execute the following code:

   public void display() {

       /* Standard GL4Java Init */
       if( glj.gljMakeCurrent() == false ) {
           return;
       }

       for (int iCurrentPixel = 0;
            iCurrentPixel<maiTestPixels.length;
            iCurrentPixel++) {
           maiTestPixels[iCurrentPixel] = (iCurrentPixel*i);
       }

       gl.glClear(GL_COLOR_BUFFER_BIT);
       gl.glRasterPos2i(0, 0);

       gl.glDrawPixels(640,
                       480,
                       GL_BGRA,
                       GL_UNSIGNED_BYTE,
                       maiTestPixels);
       glj.gljSwap();
       glj.gljFree();
   }

in the display() method of a GLAnimCanvas.  This code flies on 
MacOSX(40fps), and drags on
Win32 (1fps).  I am wondering if anyone here has any idea why 2D imaging 
stuff on windows is
so slow.

All comments are greatly appreciated.

                    Peace, Love, and Hair Grease . . .

                          -TOBY

Re: [gl4java-usergroup] GLCanvas Dispose on NT

[<NM...@th...>]

Hi,

After doing some debugging I made the following change to my source.

In file : OpenGL_Win32_jawt.c
In the method : gljDestroyNative

We were trying to delete a context with : disp__wglDeleteContext(gc). An
error was occurring on my system (WinNT), I think, because the context
being deleted (gc) belonged to a thread other than the current thread and
thus threw an EXCEPTION_ACCESS_VIOLATION.
Previous to this (a few lines up from the above) we were calling  :
disp__wglMakeCurrent( NULL, NULL ) , which detaches the rendering context
from the current thread and makes it non-current, in preparation for
deletion. This call, however, was failing on my system. I am assuming it
was failing, again, because the current thread did not hold the rendering
context.

I am not exactly sure why the thread did not own the context. I must admit,
my experience with GL Windows programming is very limited. But here is what
I did to fix my error :

I changed disp__wglMakeCurrent( NULL, NULL ) to disp__wglMakeCurrent(
thisWin, gc ) so that the current thread now owns the context. Then, when
it gets around to deleting it a few lines later, no error occurs. According
to MSDN the disp__wglDeleteContext(gc) call will actually change the
rendering context to being non-current before deleting so really the
original disp__wglMakeCurrent( NULL, NULL ) was redundant. The only
important thing is to make sure that the current thread owns the context
before deleting it.

Is it a hack? I don't know. Thoughts? It has stopped my error though.

Thanks,
Noah Keen




|---------+--------------------------------------------->
|         |           "Kenneth B. Russell"              |
|         |           <kbr...@al...>           |
|         |           Sent by:                          |
|         |           gl4...@li...ur|
|         |           ceforge.net                       |
|         |                                             |
|         |                                             |
|         |           03/26/2002 12:03 AM               |
|         |           Please respond to kbrussel        |
|         |                                             |
|---------+--------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       NM...@th...                                                      |
  |       cc:       gl4...@li...                                      |
  |       Subject:  Re: [gl4java-usergroup] GLCanvas Dispose on NT                               |
  >----------------------------------------------------------------------------------------------|





> My application needs to swap a GLCanvas and a JPanel in and out of a GUI
> Container(JSplitPane). Currently I am destroying a GLCanvas with
cvsDispose
> () and then rebuilding by recalling the constructor with each swap.
>
> ...
>
> On a WinNT machine this call causes a EXCEPTION_ACCESS_VIOLATION outside
of
> the Java VM. It is happening in the gljDestroyNative() method in
> OpenGL_Win32_jawt.c when the native disp_wglDeleteContext(gc) call is
> made(Line 713).

There is pretty clearly something wrong in that code, as that
line is executing entirely inside a block guarded by "if (gc ==
0)".

Please spend some time and debug it if you can, then send in a
patch. Otherwise we'll look at it after JavaOne. BTW, Sven is in
San Francisco this week and he and I are giving a talk on OpenGL
for Java this Thursday morning at 11. If any of you are at the
conference we hope to see you there.

_______________________________________________
gl4java-usergroup mailing list
gl4...@li...
https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

[gl4java-usergroup] interesting speed-up

[Visi <vis...@ev...>]

Hi,

I've made a little test program using GLAnimCanvas/GLEventListener which
just clears the canvas and draws a rectangle. The animate fps is set to
5000, and the actual fps is printed after every 50 frames.
I use jdk 1.4, gl4java 2.8.2.0 and NT4 (ATI RAGE 128 Pro II). When I
start the app it reports about 130-150 fps. Nothing strange so far...

Now if I start a Media Player (some video), the speed increases to
340-360 fps. Could anyone explain me this?

Thx,
	Gabor

[gl4java-usergroup] WGL_ARB_pbuffer extension

[Pepijn V. E. <pep...@lu...>]

Has anyone tried using the WGL_ARB_pbuffer extension to do hw 
accelerated offscreen rendering? Maybe this could be used to get make 
the swing component hw accelerated on win32. If nobody has tried this 
before I'll probably put some time into this...

Pepijn Van Eeckhoudt

Re: [gl4java-usergroup] GLCanvas Dispose on NT

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

> My application needs to swap a GLCanvas and a JPanel in and out of a GUI
> Container(JSplitPane). Currently I am destroying a GLCanvas with cvsDispose
> () and then rebuilding by recalling the constructor with each swap.
>
> ...
>
> On a WinNT machine this call causes a EXCEPTION_ACCESS_VIOLATION outside of
> the Java VM. It is happening in the gljDestroyNative() method in
> OpenGL_Win32_jawt.c when the native disp_wglDeleteContext(gc) call is
> made(Line 713).

There is pretty clearly something wrong in that code, as that
line is executing entirely inside a block guarded by "if (gc ==
0)".

Please spend some time and debug it if you can, then send in a
patch. Otherwise we'll look at it after JavaOne. BTW, Sven is in
San Francisco this week and he and I are giving a talk on OpenGL
for Java this Thursday morning at 11. If any of you are at the
conference we hope to see you there.

[gl4java-usergroup] GLCanvas Dispose on NT

[<NM...@th...>]

Hi,

My application needs to swap a GLCanvas and a JPanel in and out of a GUI
Container(JSplitPane). Currently I am destroying a GLCanvas with cvsDispose
() and then rebuilding by recalling the constructor with each swap.

What is the proper way to dispose of a GLCanvas? Currently, I am executing
the following code :

try {
      cvsDispose();
} catch (Exception e) {
      e.printStackTrace();
}

On a WinNT machine this call causes a EXCEPTION_ACCESS_VIOLATION outside of
the Java VM. It is happening in the gljDestroyNative() method in
OpenGL_Win32_jawt.c when the native disp_wglDeleteContext(gc) call is
made(Line 713).

if(ret==JNI_TRUE)
{
      if(gc!=0) {
            disp__wglDeleteContext(gc);
      }
}

I can wrap the code in a __try/__except but when I do my application
freezes for up to a minute due to, I assume, a weird threading issue.

I've tested my application on a Win95 machine and there is no error. Only
NT. Also, I have the most recent release 2.8.2.0, Java 1.3.1, and the most
current GL dlls.

My questions are :
1) Am I making the right call to properly dispose of a GLCanvas?
2) Is this a known error? Is there a work around I am not aware of?
3) If there is no work around, can anyone suggest a way of disabling and
then re-enabling a GLCanvas without actually destroying it?  I have tried
many combinations using calls : setVisible(), setGLEnabled() but the
context is never re-enabled. I think it has something to do with the JPanel
being placed on top of the GLCanvas. Is there a combination of calls anyone
can recommend?

Your help is GREATLY appreciated.

Thanks,
Noah Keen

PS: FYI : In a recent post about platform independent gaming on
slashdot.org the following comments were made about GL4Java.
http://slashdot.org/comments.pl?sid=29967&cid=3218526

Good stuff!

Re: [gl4java-usergroup] GC Bug - fix incorporated?

[Pepijn V. E. <pep...@lu...>]

Hi Sven,
I've sent my changes to Kenneth, and I'll forward you a copy of that 
mail as well.

Pepijn

Sven Goethel wrote:
> On Tuesday 19 March 2002 17:13, Kenneth B. Russell wrote:
> 
>>>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.
>>
>>Sorry about that, I was hoping Sven would reply. If you can
>>identify just the files which have changed, please send me a
>>tar/gz or zipped archive containing just those, otherwise send me
>>the same for your entire workspace. Please delete any built DLLs,
>>.objs, etc. before zipping. If it's possible for you to make this
>>archive available on a web page or ftp site I'd appreciate it,
>>otherwise send it to me as an attachment at this address (not
>>cc'ing the email list).
>>
> 
> 
> sorry pepijn,
> 
> please offer a pure source patch with only the needed changes
> (even as an email to my address ..)
> 
> after review, talk and integration
> we may want to add you to the CVS list .. 
> 
> cheers, sven

Re: [gl4java-usergroup] GC Bug - fix incorporated?

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

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

On Tuesday 19 March 2002 17:13, Kenneth B. Russell wrote:
> > 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.
>
> Sorry about that, I was hoping Sven would reply. If you can
> identify just the files which have changed, please send me a
> tar/gz or zipped archive containing just those, otherwise send me
> the same for your entire workspace. Please delete any built DLLs,
> .objs, etc. before zipping. If it's possible for you to make this
> archive available on a web page or ftp site I'd appreciate it,
> otherwise send it to me as an attachment at this address (not
> cc'ing the email list).
>

sorry pepijn,

please offer a pure source patch with only the needed changes
(even as an email to my address ..)

after review, talk and integration
we may want to add you to the CVS list .. 

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

iD8DBQE8nTtRHdOA30NoFAARAtROAJ0WZyQoU2Ri/tvDMjdHGDzSLARiZACdFkRP
IaQ186zKJr1XkNWKAMT+jGQ=
=0bhv
-----END PGP SIGNATURE-----

[gl4java-usergroup] Re: It's official, Solaris is a pain in the....

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

> Don't get me wrong, I learned a while back that the GLContext is not
> created until the display areas are visible and realized first (a VERY
> annoying feature of all Java bindings of OpenGL).

How else should this behave? You won't be able to do any drawing
until the window is realized because glXMakeCurrent and variants
on other OSs require the widget to be passed. OpenGL for Java
gives you an init routine which lets you set up first-time OpenGL
state for a given context.


> Now, you would ask, "Well, what was in those 5 lines you skipped above?"
> Answer: a second GL4Java display and our Java3D display. So, we learned
> another hard lesson. Construct all your display windows (GL4Java and
> Java3D) including the creation of your GLCanvases *before* you make any
> of them visible on Solaris.

This isn't a Solaris issue. In general the link between the Java
binding for OpenGL and the AWT is the least stable. There are a
lot of reasons for this, including that the AWT is inherently
multithreaded (events are dispatched on the AWT thread) and
OpenGL inherently has a single-threaded rendering model. In my
opinion the now-defunct Magician binding probably had the fastest
and most robust window system link (including, to the best of my
understanding, support for hardware-accelerated rendering to
Swing widgets.) It's on my list of things to do to revisit the
OpenGL for Java code in this area and try to simplify it to make
it more robust, though doing so may require backward-incompatible
API changes so it will probably be for version 3.0.


> Here is another piece of evidence that Solaris has problems... We also
> moved the setVisible(true) call for our Java3D display down 5 lines to
> its original location. When we do this, Solaris makes that window a
> Frame (when we clearly are creating a JDialog in the code). If we move
> the setVisible(true) back up the 5 lines, then Solaris makes it a
> JDialog. *LOL* We can tell because it adds the two little window buttons
> in the upper right on the window title bar when it is a Frame. Talk
> about flakey!! The code always calls for a JDialog, but moving the call
> to setVisible(true) on the Java3D before the GL4Java windows are
> setVisible(true) causes Solaris to decide it would rather give us a
> Frame for the Java3D window.

I have no idea whether the code implementing this could be in
Swing, the X11 implementation of the AWT, or in Java3D code, but
it sounds like a bug. Please boil this down into a test case and
file it on the Java Developer's Connection at
http://developer.java.sun.com/ . Make sure to test with 1.4
before you do to ensure it hasn't already been fixed. A huge
number of improvements went into Java2D, the AWT, and Swing in
1.4, and despite the Java3D interactions the window system is
much faster and more robust than in 1.3.1.


> PS. A month back when we were struggling with this problem (one of many
> sessions), we got the Java compiler to crash on Solaris. We commented
> out one simple line in our source code, then the javac would crash every
> time when parsing the code. We uncomment that line, then the javac
> worked fine. I wouldn't have believed that one if I didn't see it with
> my own 2 eyes. *L*

Please file a bug if something like this happens.

[gl4java-usergroup] It's official, Solaris is a pain in the....

[Mark M. <pat...@lm...>]

After some painstaking detective work, we narrowed it down to the exact
calls that make our whole application crash on Solaris (but not
Windows). It was just the location of some calls to setVisible(true) for
our JDialogs that hold the GL4Java displays.

Don't get me wrong, I learned a while back that the GLContext is not
created until the display areas are visible and realized first (a VERY
annoying feature of all Java bindings of OpenGL). So, that wasn't the
problem. The setVisible(true) calls were moved in location about 5 lines
higher in our file, and that is what caused the crashing.

Now, you would ask, "Well, what was in those 5 lines you skipped above?"
Answer: a second GL4Java display and our Java3D display. So, we learned
another hard lesson. Construct all your display windows (GL4Java and
Java3D) including the creation of your GLCanvases *before* you make any
of them visible on Solaris.

Here is another piece of evidence that Solaris has problems... We also
moved the setVisible(true) call for our Java3D display down 5 lines to
its original location. When we do this, Solaris makes that window a
Frame (when we clearly are creating a JDialog in the code). If we move
the setVisible(true) back up the 5 lines, then Solaris makes it a
JDialog. *LOL* We can tell because it adds the two little window buttons
in the upper right on the window title bar when it is a Frame. Talk
about flakey!! The code always calls for a JDialog, but moving the call
to setVisible(true) on the Java3D before the GL4Java windows are
setVisible(true) causes Solaris to decide it would rather give us a
Frame for the Java3D window.

Its hard to believe that no one else has had problems with Solaris.

PS. A month back when we were struggling with this problem (one of many
sessions), we got the Java compiler to crash on Solaris. We commented
out one simple line in our source code, then the javac would crash every
time when parsing the code. We uncomment that line, then the javac
worked fine. I wouldn't have believed that one if I didn't see it with
my own 2 eyes. *L*

"Kenneth B. Russell" wrote:

> > Already did. We're using [GL4Java] 2.8.2, and SDK 1.3.1, and
> > Java3D 1.3. (We're avoiding SDK 1.4 for the moment because it
> > has a serious bug when rendering images in Swing. For example,
> > button images blink in-and-out, they show up of the wrong
> > button sometimes, and show up in other strange places.) We're
> > running on Sparc Ultra 10 with Elite 3D graphics card under
> > Solaris 8.
>
> Frankly, combining GL4Java with Java3D sounds terrifying. You
> don't know what Java3D is doing with OpenGL contexts under the
> hood; I hope you're not trying to integrate too tightly with that
> library.
>
> > > Make sure you have all of the recommended patches, especially X
> > > server patches.
> >
> > Interesting. I'll pass this on to the sys admins. Any specific
> > patch numbers you can say?
>
> Nothing specific. I have the recommended patch set on my machine
> at work and it is completely stable.
>
> If you have a specific GL4Java-only test case which crashes with
> multiple windows under Solaris but works under e.g., MS Windows,
> send it to me and I'll try to look at it.

Re: [gl4java-usergroup] Solaris, what a pain in the...

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

> That sucks. How did you initiate a shut-down without a GUI
> button, menu, or window event? I don't think we saw problems
> with this specifically, but I'm not sure.

Simple; start a new Thread just to run the System.exit() call.
Cooperatively stop running OpenGL code while the shutdown is
pending.

> Already did. We're using [GL4Java] 2.8.2, and SDK 1.3.1, and
> Java3D 1.3. (We're avoiding SDK 1.4 for the moment because it
> has a serious bug when rendering images in Swing. For example,
> button images blink in-and-out, they show up of the wrong
> button sometimes, and show up in other strange places.) We're
> running on Sparc Ultra 10 with Elite 3D graphics card under
> Solaris 8.

Frankly, combining GL4Java with Java3D sounds terrifying. You
don't know what Java3D is doing with OpenGL contexts under the
hood; I hope you're not trying to integrate too tightly with that
library.

> > Make sure you have all of the recommended patches, especially X
> > server patches.
> 
> Interesting. I'll pass this on to the sys admins. Any specific
> patch numbers you can say?

Nothing specific. I have the recommended patch set on my machine
at work and it is completely stable.

If you have a specific GL4Java-only test case which crashes with
multiple windows under Solaris but works under e.g., MS Windows,
send it to me and I'll try to look at it.

Re: [gl4java-usergroup] Solaris, what a pain in the...

[Mark M. <pat...@lm...>]

Whoops! I meant to say "GL4Java 2.8.2" (not Magician). (I bascially just stepped into
Burger King and ordered Chicken McNuggets. whoops.)

-Mark M

Mark Montana wrote:

> Comments inserted below....
>
> "Kenneth B. Russell" wrote:
>
> > > Little survey for all the GL4Java and/or Java3D developers...Do you develop
> > > or deploy your apps on Solaris?
> >
> > The GL4Java apps I've developed (largely on Windows) worked fine
> > on Solaris. A couple of minor code changes related to shutdown
> > issues, but those were due to differences between Sun's Windows
> > and X11 AWT implementations. (You can't call System.exit() from
> > the AWT thread on X11...)
> >
>
> That sucks. How did you initiate a shut-down without a GUI button, menu, or
> window event? I don't think we saw problems with this specifically, but I'm not
> sure.
>
> >
> > Suggestions: upgrade to 2.8 if you aren't already running it.
>
> Already did. We're using Magician 2.8.2, and SDK 1.3.1, and Java3D 1.3. (We're
> avoiding SDK 1.4 for the moment because it has a serious bug when rendering
> images in Swing. For example, button images blink in-and-out, they show up of the
> wrong button sometimes, and show up in other strange places.) We're running on
> Sparc Ultra 10 with Elite 3D graphics card under Solaris 8.
>
> >
> > Install the latest OpenGL for Solaris/SPARC from Sun's web site.
>
> We already did. The system admins here loaded an OS patch that updated/fixed the
> latest OpenGL install on the Sun.
>
> >
> > Make sure you have all of the recommended patches, especially X
> > server patches.
>
> Interesting. I'll pass this on to the sys admins. Any specific patch numbers you
> can say?

Re: [gl4java-usergroup] Solaris, what a pain in the...

[Mark M. <pat...@lm...>]

Comments inserted below....

"Kenneth B. Russell" wrote:

> > Little survey for all the GL4Java and/or Java3D developers...Do you develop
> > or deploy your apps on Solaris?
>
> The GL4Java apps I've developed (largely on Windows) worked fine
> on Solaris. A couple of minor code changes related to shutdown
> issues, but those were due to differences between Sun's Windows
> and X11 AWT implementations. (You can't call System.exit() from
> the AWT thread on X11...)
>

That sucks. How did you initiate a shut-down without a GUI button, menu, or
window event? I don't think we saw problems with this specifically, but I'm not
sure.

>
> Suggestions: upgrade to 2.8 if you aren't already running it.

Already did. We're using Magician 2.8.2, and SDK 1.3.1, and Java3D 1.3. (We're
avoiding SDK 1.4 for the moment because it has a serious bug when rendering
images in Swing. For example, button images blink in-and-out, they show up of the
wrong button sometimes, and show up in other strange places.) We're running on
Sparc Ultra 10 with Elite 3D graphics card under Solaris 8.

>
> Install the latest OpenGL for Solaris/SPARC from Sun's web site.

We already did. The system admins here loaded an OS patch that updated/fixed the
latest OpenGL install on the Sun.

>
> Make sure you have all of the recommended patches, especially X
> server patches.

Interesting. I'll pass this on to the sys admins. Any specific patch numbers you
can say?

Re: [gl4java-usergroup] Solaris, what a pain in the...

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

> Little survey for all the GL4Java and/or Java3D developers...Do you develop
> or deploy your apps on Solaris?

The GL4Java apps I've developed (largely on Windows) worked fine
on Solaris. A couple of minor code changes related to shutdown
issues, but those were due to differences between Sun's Windows
and X11 AWT implementations. (You can't call System.exit() from
the AWT thread on X11...)

Suggestions: upgrade to 2.8 if you aren't already running it.
Install the latest OpenGL for Solaris/SPARC from Sun's web site.
Make sure you have all of the recommended patches, especially X
server patches.

[gl4java-usergroup] Solaris, what a pain in the...

[Mark M. <pat...@lm...>]

Little survey for all the GL4Java and/or Java3D developers...Do you develop
or deploy your apps on Solaris?

We developed our Java app on Windows using both GL4Java and Java3D in two
different windows (JDialogs). It runs like a champ on Windows, always has. It
has never run on Solaris. In fact, it didn't even run back when we were using
Magician and Java3D. Each display ran fine separately, but if both windows
were enabled at compile time (Magician and Java3D windows), then it never
ran. Now we have switched to GL4Java and reachitected, and we got it to run
for a brief period of time. Then after a few minor changes (really unrelated
to rendering), it stopped running again. In fact, we can't even get 2 GL4Java
windows to come up together in the app without an exception in native code.
We have been struggling off-and-on with Solaris for 4-5 months now. I wish I
could give a stack trace or error message here, but it changes from
run-to-run most of the time. Currently, it throws an exception originating in
glCallList and ending in native code. Has anyone else had problems like this
on Solaris?

-Mark M

[gl4java-usergroup] Re: osx & swing problems

[gerard z. <gzi...@ap...>]

Daniel

The hwaccel mechanism in Apple's Java implementation uses 
OpenGL. Currently, if you turn hwaccel on, you will run into 
problems if you try to run gl4java at the same time. It should 
be easy to make gl4java work with hwaccel, after all, they use 
the same hardware accelerated surface, so the entire step of 
gl4java asking and pinning down its own hwaccel surface goes 
away. But it takes time, however little, to do it and right now 
I'm busy working on Java and preparing for WWDC. After all what 
good is gl4java without kick ass Java support underneath it 
right? ;-)

I will look at gl4java shortly and update it.

cheers


> Date: Sat, 16 Mar 2002 23:34:40 +0100
> From: Daniel Bisig <db...@if...>
> To: gl4...@li...
> Subject: [gl4java-usergroup] osx & swing problems
>
> Hi all,
>
> I trying to get the swing demo files to run under Mac OS X 10.1.3. The
> gl4java Version is 2.7.2.0. which I downloaded from Gerard 
> Ziemski page.
> At the moment, these demos and all the other examples that I 
> found which
> make use of either GLAnimPanel or GLJPanel produce the follwing
> exception:
>
> An exception is thrown, while creating a GL context
>
> java.lang.ClassCastException:
> com.apple.mrj.internal.awt.basepeers.VContainerPeer
> java.lang.ClassCastException:
> com.apple.mrj.internal.awt.basepeers.VContainerPeer
> ...etc...
>
> I have no clue whether this is a problem of apple's java implementation
> or of gl4java. I would really like to include some opengl functionality
> in my visualization program which makes heavy use of swing. For this
> reason I appreciate any tips and tricks how to get gl4java and swing to
> work under Mac OS X.
>
> Thanks in advance!
>
>         Daniel

Re: [gl4java-usergroup] Request to developers of GL4Java

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

> Would you have some time in the near future to examine and
> incorporate Pepijn's fixes to the tesselator memory management?
> Overall I am really happy with GL4Java, and we want to continue
> using it for our product. The tesselator bug and the inability
> to share GLContexts under the GLEventListener paradigm are the
> only two issues we've found to date. It would be a great help
> to have at least one of them fixed in the official release.

I'll work on incorporating Pepijn's fixes to the tesselator.

We need more people to feel comfortable making changes to the
source base. If you could add support to the GLDrawableFactory
and GLCanvas/GLJPanel hierarchy for sharing contexts (which
should be easy; no native code needed) I'll fold it in to the
workspace.

Re: [gl4java-usergroup] GC Bug - fix incorporated?

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

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

Sorry about that, I was hoping Sven would reply. If you can
identify just the files which have changed, please send me a
tar/gz or zipped archive containing just those, otherwise send me
the same for your entire workspace. Please delete any built DLLs,
.objs, etc. before zipping. If it's possible for you to make this
archive available on a web page or ftp site I'd appreciate it,
otherwise send it to me as an attachment at this address (not
cc'ing the email list).

Re: [gl4java-usergroup] GC Bug - fix incorporated?

[Pepijn V. E. <pep...@lu...>]

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
>

[gl4java-usergroup] Request to developers of GL4Java

[Mark M. <pat...@lm...>]

Sven, Kurt,

Would you have some time in the near future to examine and incorporate Pepijn's
fixes to the tesselator memory management? Overall I am really happy with
GL4Java, and we want to continue using it for our product. The tesselator bug
and the inability to share GLContexts under the GLEventListener paradigm are the
only two issues we've found to date. It would be a great help to have at least
one of them fixed in the official release.

Thanks for your consideration,
Mark M

pep...@lu... wrote:

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

Re: [gl4java-usergroup] GC Bug - fix incorporated?

[<pep...@lu...>]

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
>

[gl4java-usergroup] GC Bug - fix incorporated?

[Mark M. <pat...@lm...>]

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