Canvas inside JSplitPane

[MAHAH]

Sponsored Links

I have a problem of interoperability between JAVA components of AWT and Swing: I included an JSplitPane (which splits vertically) in a JFrame and I put inside a AWT Canvas and a JTextArea, the first above and below the second. The problem is that the Canvas is refusing to shrink: the user is unable to raise the splitter but only to lower it. I can zoom around the JFrame as this would cause a shrinkage of the Canvas. Of course if I post a JPanel instead of Canvas everything worked properly. Does anyone know another way to correct this?

One more thing: under construction of GUI Canvas.setPreferredSize, I have called for making one's calling pack () performed on the final JFrame bring me to the Canvas to a minimum. In other words I wish that when the application is the Canvas had a certain size, but also that the user is able to raise the splitter and to shrink the JFrame.

[CodGuru]

Look, if I remember correctly was discouraged by the sun itself using AWT and Swing components together. And among other things by now you should only use swing. Why did you need this?

[MAHAH]

Because in reality it is not exactly a canvas but a GLCanvas of JOGL (which inherits Canvas). I know that there is also GLJPanel JOGL, but instead is discouraged by the team of JOGL because it is less helpful

So if I can make my GUI with GLCanvas. This should be the last problem left: in addition to this I had only problem with the fact that the Canvas is heavyweight and hide the menu.

[CitricAcid]

but instead is discouraged by the team of JOGL because it is less helpful

Are you sure it is still not recommended?

I ask because years ago to build a viewer for 3D models for CAM software we had the same necessity for performance reasons.

Then later, when the JOGL have become "more mature" in parallel to improvements on Swing side, we could upgrade to JPanel with no loss of performance (of course then it depends on what you have to render).

So if I were you then I would have first tried with GLJPanel, and then only after having seen the actual loss of performance (and has verified with a profile which is the actual bottleneck, another lesson learned on my skin) as surely attributable to the GLJPanel replacing it with GLCanvas.

In the latter case, you must devise some strategy to integrate it into IU minimizing interoperability problems that occur when you mix AWT components with Swing components.

[MAHAH]

After reading the various guides, I see that now the situation has improved, but the performances are still comparable. The reason is that JPanel (which inherits GLJPanel) is a lightweight component and as such has a native window (typically in the native environment to do rendering with OpenGL is a window dedicated to native on which we can do just that and we can not render nothing else), and if we add a JPanel that should also optionally be made partially transparent, the most reasonable solution for the JOGL team was that when drawing on a GLJPanel no designs on screen but will grab the contents of frame buffer with glReadPixels or similar and that content is then rendered on GLJPanel with any semi-transparent. This solution perfectly reasonable, is inherently less performing the operation of a Canvas, as it can optimize.