Re: Canvas inside JSplitPane
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?
Re: Canvas inside JSplitPane
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.
Re: Canvas inside JSplitPane
Quote:
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.
Re: Canvas inside JSplitPane
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.