Hi  there.

We have a small problem with the way GLCanvas automatically grabs the focus and raises itself on mouse entry as this interfers with most of our popups and dialogs which suddenly find themselves closed or below a GLCanvas (in a Dialog).

We're currently using JOGL 1.0 (pre JSR version) but I think it's in the JSR version too.

Would be possible to get included the switching on/off of this auto-raising and auto-focus via parameters (-Djogl.autoraise=true and -Djobl.autofocus=true for example)?

Thanks.

Hi Ken.

My project is using JOGL and love it, so thanks, but we're an industrial and project and have some issues with upgrading to informal/incomplete versions of COTS.

Have you got a planned schedule for a final JSR-JOGL-1.1.1 release or are there still featuers missing that are planned?

Thanks.

Greg

Any chance you can make an eclipse update site for this rather than just providing the zip files?   

We've got a small problem in our basic "graphics drawing" tool in our application when drawing non-filled circles over the top of a filled circle resulting in the "mesh" of the filled circle being drawn rather than just a filled circle.

There is no problem when drawing the two different circles apart from each other, but when the un-filled overlaps the filled circle, the error is as above.

From memory our circle drawing routine is using gluDisk but I don't remember exactly. I'll need to check tomorrow.

Windows XP, JOGL 1.1.1, Java 1.5.0_04 (might be 02, not sure on that developer's machine), Eclipse 3.1.
Sorry for the lack of other details or code samples but they're at work, and I wanted to post this off this evening.

Cheers for any ideas.

Can you tell us why it will lead to conflicts?  I've seen it suggested to place it there before and that's where i always put any of my required extensions rather than add things to the system classpath etc.

This is something i've seen irregularly over the past couple of years.  On the odd occasion it happens under windows.  Sometimes under linux it happens every time, until I restart eclipse or even reboot, but then it's ok.  Quite strange, but thankfully not too regular these days.

Don't forget, if you want your frame rate to exceed your monitor refresh rate you will have to disable vertical sync, normally in your driver settings.

There's also an entire thread on this forum somewhere covering a TextureManager for loading and managing textures.  It was being extended some time ago to include avi and quicktime stuff as well but it's been a quiet thread for some time.

Assuming I'm actually on the right bandwidth with you, i've not had to do anything special in the past when it comes to effecting the alpha/translucency of a textured area.

Just glColor(red, green, blue, ALPHA); then draw your textured area, and the area is as translucent as the alpha I use.

I've just given this a burl on my Inspiron 9200 w/ latest released JOGL, JDK1.5.0_4.
Funnily enough I get a mixture of the good and the bad.  I don't get the wireframe stauff over the base/spring/ball.  They're all nice and solid.
However, I don't get the text inside the yellow boxes.

One thing I DO get is clipping at the near plane during rotation.  You might want to change your near value in your ortho/perspective.

Invert the y coordinates in the vertexes (as opposed to the tex coords) as your subdividing your texture image?

You could also swap the Y coordinates of the top and bottom corners in your glOrtho call so your canvas Y coordinate system matches what swing uses.

Hi Ken.

Unfortuantely for commercial reasons I cannot make my application available.  I can try and put together a simple example of multiple canvases in different windows and see if it's as simple as that.

The hardware that the problem occurs on is Redhat 9, Xi Graphics' Summit X server (in lieu of XOrg/XFree86) and a 3DLabs Wildcat VP880Pro.  I've not got any other linux hardware handy to test the problem at the moment.

Thanks.

Greg.

Write yourself a little test application that opens a window with a JColorChooser in it.  Very helpful.
Also I have a preference to use bytes (glColour3ub((byte)255,...) rather than floats so I can just use RGB values between 0 and 255.  No idea of any performance hit b/w this and floats.

I'm just using the FpsAnimator with 25fps so there is no load on the position. I'm not sure about thread starvation because all of the application continues to work just fine, including all the Swing components updating fine.

Just to clarify, it's not that i'm constantly resizing the canvas, it's just that the action of resizing a canvas seems to be the prime (but not the only) cause of this disconnection.  Once I stop resizing a canvas (at some time during really) all of the canvases (1 to 4 may be open) stop being redrawn by their respective FpsAnimators.

The canvas just stops redrawing and the ONLY way to get it to refresh is by moving some other window over the canvas.  It's very strange.  All of my actions are managed but not visibly update, i.e. i can zoom and pan my scene with the mouse but i don't actually see any changes until i trigger some refresh action with an exposure event.

Very strange.

I'm experiencing a strange problem when running my application on Linux (but it's ok on Windows).

For some reason, although I'm yet to do a complete analysis, particularly if I'm resizing my second canvas (in a JFrame), the canvases stop refreshing unless I do something that causes an exposure/redraw event (via AWT?) on the canvas, i.e. move another window over the canvas(es).

I've not had a chance to see if the if the canvas isn't informing it's listeners or if the animator itself gets stuck, but it definitely only occurs on Linux (Redhat 9) and not on Windows XP.

JDK 1.5.0_02 on both platforms
JOGL 1.1.b12 on Linux (but in fact on all versions to date).

Hence their desire for transparency in those windows that overlay the primary view.  :/

Well, that's pretty handy, and typical, isn't it!  :/

I've definitely noticed massive performance differences between the CLCanvas and the GLJPanel.

For me to achieve a translucent window system I had to use JDesktop JInternalFrames.  I couldn't seem to find a way to draw JInternalFrames as heavyweight and hence other windows were were always below my JInternalFrames with a GLCanvas in it, hence my switch to the GLJPanel.  If I can find a way to use the GLCanvas instead, i'll be back in performance heaven.  At the moment I'm pretty much buggered the way it is now.  Any suggestions?

One of my French colleagues has had Redhat 9 + XFree86 + DRI with on a Dell Inspiron 9100 w/ Radeon 9700 Mobility successfully running some time ago.  It's definitely possible.

G.

I've also just replaced the GLJPanel with a GLCanvas, and the GLCanvas retains the same (high) performance regardless of the size of the canvas whereas the GLJPanel degrades significantly the larger the canvas.

I've just discovered that my Inspiron 9200 had 1.1b11 as opposed to the b12 at work.  I've just upgrade to b12 and now i'm getting the context recreation (that causes a flickering/pause when it occurs) during recreation.

Further to this, I've noticed rapid degradation of performance with GLJPanel during resizing.  As I resize the panel to various sizes and the context is recreated (and hence reinitialised), each time this occurs the performance degrades quickly down to 1fps.

This is with a GLJPanel inside a JInternalFrame.

JOGL 1.1b12
Java 1.5.0_02
Windows XP
Dell Inspiron 9100 (3.2GHz P4) Radeon Mobility 9700 (I think with the Dell drivers) and also on a Dell Desktop w/ 3.0GHz P4 + NVdia 5260 (or something).

Interestingly I don't experience the quite same degradation on my Inspiron 9200 (Centrino 2.1GHz) Radeon Mobility 9700 w/ DNA Drivers.

jogl.jar is not platform specific.  it's the core java API and is cross platform.

it's the native jars that contain the *.dll, *.so, etc, that are platform specific.

That's interesting.  I'm using JDK 5.0.2.

Is it normal to receive many calls to init(GLDrawawable) during resizing a drawable?

I've placed a GLJPanel inside a JInternalFrame and when I resize it, not only does init() get called many times on my GLEventListener during the resize but the performance degrades significantly.

Thanks for the suggestion Ken.  With a little more targeted dogpiling (the meta-search-engine, not some wierd Australian game) I was able to track down a few other sources.

As a result, I have developed a simple sample (sorry) using a JDesktopPane and JInternalPane(s) where the internal panes are either transparent or translucent. No robot, no grabbing pixels, etc.

Now I just have to incorporate a GLJPanel, and away we go.  

I'll keep you posted.

Greg.

Thanks for the responses guys.



This seems to only not redraw it during resizing.
I've set up a JFrame with no other components.
The window shows the default light blue color (I think) .  If I don't set the property, then it resizes and retains it's color.  If I set the property to true, then it shows through during resize, but leaves rubbish behind at intervals where the border was as it resized, and it also fills out with colour when i finish the resize.  unfortunately not transparent.

Perhaps i'm missing something.




This smells very CPU intensive.  Especially when I will have at least one canvas the size of the screen ALWAYS as the bottom-most window.  if I have to grab a texture for every window that's open over the canvas 23 times per second (if thats my refresh rate), this is going to hurt performance hugely.

Hmmmm.

Ken, I'll have to read your response again, perhaps a few times, to see what I have to do on that idea.  

Ta.

Greg.

I'm facing pressure from my system engineers to tell them I can do transparent windows.

Part of this means I need transparency in my windows with glcanvases on them.

Is there any way to do this?

Thanks for any advice.

Greg.

ps. if you hav any advice on simply doing it in a java window i'd also like to know.  

this has appeared a few times in the forums.  i suggest you do a search.
however,  take a look at setting the jmenuitem to draw as a heavyweight component.  normally they are lightweight and will be draw UNDER the heavyweight canvas.  if you make it heavy too it will draw ABOVE the canvas.