I can set fullscreen without a hitch with JoGL but when I switch back the canvas doesn’t seem to resize properly.
After I resize the frame the canvas is in I specifically set the size of the canvas using setSize and it works.
Err, this is more of a bug report/clarification type post as half way through writing it I decided to try the obvious (well, the third obvious thing… after trying to get the canvas to resize by making a direct call to reshape with some not entirely expected results).
I did download the 1.1 beta 3 drivers and the problem still existed.
What OS, JDK, graphics card, etc.?
Are you specifying -Dsun.java2d.noddraw=true when launching the VM? That is basically required for all JOGL applications on Windows, in particular when using the JDK’s full-screen support in conjunction with JOGL.
There was a “bug” in the original GL4Java code where on resizing a window, the GLCanvas would set it’s minimum size making it impossible to resize the canvas smaller once it was resized larger.
Because in GL4Java the GLCanvas wasn’t a final class, a solution was to subclass the canvas, and over-ride the resizing stuff.
This bug seems to also exist in the JOGL 1.0 code (haven’t checked in v1.1), but due to it now being a final class, I guess there’s no “clean” solution. Mind you, I haven’t spent any time investigating further since switching to JOGL.
Has anyone else seen this, and have a simple (clean) solution?
Greg.
The cleanest solution I have is calling setSize on the canvas after resizing the frame which seems to work fine, it’s just that I expected different behavior.
I’m using windows 98 se, jdk 1.4.0 and 1.5b1 (I had a lot of trouble with the new sun ddraw junk which is why I was using 1.4.0 instead of 1.4.2_??), ATI radeon 7500 all in wonder (I HATE THIS CARD!!! but at least the drivers have improved enough that it’s better than the old Nvidia TNT card I had). I haven’t been setting any properties on startup and haven’t had any big problems that I’ve seen.
Do you have more information about the kinds of problems that are common with leaving ddraw on (besides the horrors of the ATI card crashes)? On a different computer than the one I develope on fullscreen mode caused a white screen and I think it was followed by some other problems, but I don’t know if that issue was related to windows xp, the fact it was a laptop with a possibly ‘strange’ video card in it, or any other issues such as me just doing something wrong (it happens). I haven’t had a chance to investigate that problem yet.
[quote]This bug seems to also exist in the JOGL 1.0 code (haven’t checked in v1.1), but due to it now being a final class, I guess there’s no “clean” solution. Mind you, I haven’t spent any time investigating further since switching to JOGL.
Has anyone else seen this, and have a simple (clean) solution?
[/quote]
The JOGL reshape() code doesn’t do anything explicit with the minimum size, but it does call super.reshape(). I think there have been issues raised in the forums before about whether the GLCanvas should override set/getPreferred/Maximum/MinimumSize, but I don’t see any related issues in the issue tracker. If you have a test case which shows that this should be done, please file an issue. I looked at the source code for the AWT Component in 1.5 and I think some of the functionality was hoisted up from JComponent, so maybe this will not be an issue as of 1.5.
[quote]Do you have more information about the kinds of problems that are common with leaving ddraw on (besides the horrors of the ATI card crashes)?
[/quote]
I think it’s safe to say that hangs, crashes and incorrect drawing (most likely of Swing widgets) can be expected if -Dsun.java2d.noddraw=true is not specified. In the same way that the AWT stresses graphics card drivers more than most C programs because of the AWT’s multithreaded nature, I think that Java2D’s use of DirectDraw and JOGL’s use of OpenGL uncover more issues caused by mixing these two APIs in the same application than most other applications would.
I’m not mixing swing with jogl in the same frame, but I have been using some swing (it goes into it’s own pop-up frame), typically the swing components aren’t even instatiated (they are used for level editting but normal play doesn’t require them). I was using the 1.5 beta (not sure why I didn’t mention it when I mentioned 1.4.0) when I hit this problem, so at least in the beta the results haven’t changed. I don’t think it’s related to minimum size or preferred size, so much as not being aware of it’s own resizing downward (increasing the size it seems to notice but decreasing is somehow ignored).
I had encountered a problem where if I maximized a window and then un-maximized it, I’d have lockups pretty consistantly, this was also true of resizing the window by dragging the corner. It never locked up when increasing the size but almost always did while decreasing size. I’m not sure if the two are related or if it’s an issue caused by the AWT doing nasty things to the GLCanvas while it’s busy redrawing itself or something (it caused HARD lockups where the mouse still drew and moved I believe but nothing else worked and had to push power to shut it off).