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 ^_^
Can you post any code?
QuoteI 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 ;D
Quote from: Fool Running on July 03, 2008, 14:47:20
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.
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.
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.
^_^
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!
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 !
Could you expand on this further, as I don't know what you mean.
Quote from: broumbroum on January 16, 2009, 21:12:59
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 !
http://java.sun.com/products/jfc/tsc/articles/mixing/#issues - specifically the 'Swing popup components' part.
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.
Quote from: Matzon on January 18, 2009, 08:51:43
http://java.sun.com/products/jfc/tsc/articles/mixing/#issues - specifically the 'Swing popup components' part.
Quote from: DanDanger on January 20, 2009, 09:20:30
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.