Bug 135

---- Reported by kbr 2005-01-31 16:36:03 ----

Several issues were raised roughly a year and a half ago, when JOGL was
introduced, indicating that GLCanvas should behave better when placed in the
midst of lightweight components; in particular, that it should respect
setMinimumSize, setPreferredSize, and setMaximumSize, as I understand that
lightweight widgets do. We should investigate this issue and provide such
support. See JOGL Issue 17 for an example which seems to misbehave when Swing
widgets surround a GLCanvas.



---- Additional Comments From kbr 2005-05-01 12:34:03 ----

Created an attachment
Test case illustrating problem




---- Additional Comments From kbr 2005-05-01 13:12:17 ----

This has come up again on the JOGL forum on javagaming.org:
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1114904448

This problem appears to have no good solution. The root cause is behavior of the
Canvas, and in particular its ComponentPeer. The implementation of
getPreferredSize() calls getMinimumSize() and getMinimumSize() turns around and
calls Component.getSize(). This effectively means that the Canvas will report
its preferred size as being as large as the component has ever been. For some
layout managers this doesn't seem to matter, but for others like the BoxLayout
it does. See the attached test case for an example. Replacing the GLCanvas with
an ordinary Canvas yields the same behavior.

One suggestion was to override getPreferredSize() so that if a preferred size
has not been set by the user, to default to (0, 0). This works fine for the
supplied test case but breaks all of the other demos because they use a
different LayoutManager. There appear to be a lot of interactions between
heavyweight vs. lightweight widgets and layout managers. One experiment which
was done was to override setSize() in GLCanvas to update the preferred size.
This works down to the size specified by the user; if the window is resized any
smeller the same problem appears. If reshape() (the base routine of setSize(),
setBounds(), etc.) is changed to do the same thing, the demo breaks in the same
way it originally did. Therefore this solution is fragile because it isn't clear
which of these methods are used internally by the AWT and for what purposes.

There are two possible workarounds, both application-specific. The best and most
portable appears to be to put the GLCanvas into a JPanel and set the JPanel's
preferred size to (0, 0). The JPanel will cause this constraint to be enforced
on its contained GLCanvas. The other workaround is to call setPreferredSize(new
Dimension(0, 0)) on a newly-created GLCanvas; this method is new in 1.5.

This bug is being marked as "wontfix" because the behavior is unchanged from the
underlying Canvas class and it looks like making any change is going to break
something else.




---- Additional Comments From kbr 2005-05-01 13:13:31 ----

Created an attachment
Test case from JOGL forums including commented-out workaround




---- Additional Comments From moorej 2007-11-30 10:42:15 ----

Created an attachment
Updated resize issue to include new workaround and make it work with the ratified jogl release




--- Bug imported by sgothel@jausoft.com 2010-03-24 07:47 EDT  ---

This bug was previously known as _bug_ 135 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=135
Imported an attachment (id=38)
Imported an attachment (id=39)
Imported an attachment (id=40)

The original submitter of attachment 38 [details] is unknown.
   Reassigning to the person who moved it here: sgothel@jausoft.com.
The original submitter of attachment 39 [details] is unknown.
   Reassigning to the person who moved it here: sgothel@jausoft.com.
The original submitter of attachment 40 [details] is unknown.
   Reassigning to the person who moved it here: sgothel@jausoft.com.