AWTGLCanvas in java 6

[DanDanger]

Hi all,

I've got a new problem which I think started when moving to java 6.
I have a swing application which implements an AWTGLCanvas based object.
The problem I'm having is that whenever I switch application, bring up a jpopupmenu or activate a menu, the AWTGLCanvas view seems to be overwritten (as though the component was being cleared with the background color) and the AWTGLCanvas buffer wont get displayed until I force a redraw on it.

Has anyone else come accross this problem? If so any help would be most appreciated ^_^

[Fool Running]

Can you post any code?

I have a swing application which implements an AWTGLCanvas based object.

What exactly do you mean by this? Do you mean you have a class that derives from AWTGLCanvas? If so, you need to override the paintGL() method. You also need to make sure you do a swapBuffers() after you are done drawing (I don't think its done for you). After that, painting should happen automatically.

Hope that helps

[DanDanger]

Can you post any code?

Not really its quite a large project.

This application I have used to run fine (on older versions of java and lwjgl) however now whenever a menu popups up the opengl view gets cleared by the background color. Im guessing its swing clearing the view for some reason I just cant seem to stop it doing it.

[dronus]

I have seen this some time ago too! Usually with animated graphics, you have a continous redraw loop. Under some circumstances (maybe driver, os dependent) a popup menu triggers some kind of clear, visible as flickering bg colour between the frames. If you do all your  drawing inside paintGL() as you should, and still experience this problems, it is definitely some lwjgl fault as I would say. For the lwjgl maintainers I can propose to try out some less potent GPUs (onboard's) on linux machines, where I encountered this error.

[DanDanger]

Hello,

I'm still trying to fix this problem but have been unable to find a solution.
My canvas is inherited from AWTGLCanvas and everything draws fine, except when I min/maximise the app  or bring up a menu that overlaps the canvas. The canvas always gets cleared to whatever background color the AWTGLCanvas is set to.

This is probably a bug in the way LWJGL is interacting with java6 i would imagine.

I have included 3 screen shots.

"parta.jpg" shows the app rendering normally
"partb.jpg" shows the menu up
"partc.jpg" shows when the menu dissapears

the AWTGLCanvas background color has been set to red.


^_^

[DanDanger]

Fixed it by setting this parameter in the VM arguments

-Dsun.java2d.noddraw=true

Which disables direct draw or some such. And means the opengl view does not get cleared after a menu dissapears. YAY!

[broumbroum]

this can be also corrected with enabling/disabling the lightweight popup, which in this case has to be disabled. It's JPopup option. See Javadoc 6 !

[DanDanger]

Could you expand on this further, as I don't know what you mean.

this can be also corrected with enabling/disabling the lightweight popup, which in this case has to be disabled. It's JPopup option. See Javadoc 6 !

[Matzon]

http://java.sun.com/products/jfc/tsc/articles/mixing/#issues - specifically the 'Swing popup components' part.

[DanDanger]

Got you,

However the problem i was having was above and beyond the traditional lightweight vs heavyweight issue. The only way i could solve the problem was with the "-Dsun.java2d.noddraw=true" flag. Toggling setDefaultLightWeightPopupEnabled() would not solve the problem i outlined.

http://java.sun.com/products/jfc/tsc/articles/mixing/#issues - specifically the 'Swing popup components' part.

[wolf_m]

Got you,

However the problem i was having was above and beyond the traditional lightweight vs heavyweight issue. The only way i could solve the problem was with the "-Dsun.java2d.noddraw=true" flag. Toggling setDefaultLightWeightPopupEnabled() would not solve the problem i outlined.

I fixed a similar issue in exactly the same way in a Swing-based app with an AWTGLCanvas I recently completed.

It's necessary to do this to handle the redrawing problem upon moving the canvas out of screen space, it seems. I didn't have the redrawing problem related to popups you mentioned above though.