Hi all,
I want to use a GLCanvas in an AWT scrollpane for an image processing application. I understand that using a GLCanvas and awt scrollpane should give me better performance than using a GLJpanel in a JScrollpane. In the GLcanvas, I will show an image and using the mouse wheel/buttons, users can zoom in/out on the images. I project my data parrallel using glortho and set the viewport for the whole size of the GLCanvas. As soon as the GLCanvas becomes bigger then the scrollpane viewport, image drawing in the GLCanvas is completely messed up. So when the GLviewport becomes larger than the scrollpane viewport, everyhing is off, aspect ratio of the images is clearly wrong and even depends on the aspect ratio of the scrollpane viewport it seems. Could the problem be that the GLCanvas is partly obscured due to having it in a scrollpane? And if so, what would be the most efficient way to deal with this. I am trying with offscreen drawing using either a offscreen gldrawable or a Frame Bufffer Object. Drawing is fine offscreen, I have tested this by saving the offscreen drawing to a BufferedImage and then to a file. That looks perfect. As soon as I try try to render the offscreen data on the GLCanvas, I get the exact same problem unfortunately. So my main question is this: Could the problem be that the GLCanvas is partly obscured due to having it in a scrollpane? And if so, what would be the most efficient way to deal with this. Kind regards, Mabula |
Administrator
|
Hey
GLJPanel has an higher memory footprint and is slower than GLCanvas on some machines but I advise you to give it a try anyway. If I were you, I would simply remove the scroll pane and use a combination of keys and mouse moves to scroll or resize the GLCanvas when the scrollpane viewport is resized.
Julien Gouesse | Personal blog | Website
|
Hi Julien,
Thank you very much for replying to my question. I have tried all sorts of configurations. - a GLJpanel in a JScrollpane - a GLCanvas in a awt Scrollpane - a NEWTCanvasAWT in a awt Scrollpane All 3 configuration manifest the same problem: if drawing outside the scrollpane viewport is needed due to zooming in on the data (thereby increasing the size of the GLJPanel, GLCanvas, NEWTCanvasAWT) triggers the drawing that is seen inside the scrollpane to be off. I have checked my gl commands for errors with glErrorGet(). I have also double checked all dimensions and my calculations by sending all relevant info to system out. They are all what they need to be and still the gl drawing is not correct. My suspicion is that this is somehow related to drawing to a component which is only partly visible and that upsets the opengl rendering somehow. I must point out, i am pretty new to OpenGL, so I am still trying and reading all relevant documentation to verify if I missed something. So you would suggest to use key and mouse listeners that will trigger the scrolling without having any scrollbars? Is that a common inplementation? I can imagine how to do this however. Is there a technical/documented reason why to just skip using a scrollpane? Perhaps the opengl rendering itself to screen? Thanks, Mabula |
Administrator
|
Hey
Not drawing what is outside the viewport is the expected behaviour, it's not a bug. This is what I try to use as a source of inspiration when I use AWT and Swing to draw zoomable images: https://community.oracle.com/docs/DOC-983610 Actually, I would better understand what you do if you provided a SSCCE. How do you draw your images? Do you use AWT or do you create a texture to draw it with JOGL?
Julien Gouesse | Personal blog | Website
|
Hi Julien,
"not drawing what is outside the viewport is the expected behaviour, it's not a bug. " I understand this, but I would still expect the drawing inside the scollpane viewport to have correct size and aspect ratio if the glviewport is larger than the scrollpane viewport. It seems that opengl internally does something with the glviewport and so it gets distorted. But I am completely guessing here. Thank you for the reference, highly appreciated ;-) I will give it a good read. Yes, I haven't been entirely clear. I am drawing the images to a 2D texture with mipmapping and then rendering the texture as a quad to the glviewport using orthographic projection with glortho. The same code for redering the image texture works perfectly offscreen using either a offscreen auto drawable or a Frame Buffer Object. But if I want to render it to the canvas which is partly obscured, all goes wrong. If I adjust the aspect ratio of the scrollpane viewport, the aspect ratio of the visble drawing changes as well, really strange. Therefore I can only conclude that openGL internally won't handle this proberly. And I probably shouldn't try drawing to pixels that can't be seen actually, after having read more documentation. I'll try to create a SSCCE if you want to see this. Do you think it's helpfull or would you agree my problem is probably due to trying to do something that will simply not work? Since the scrollpane solution is giving me so much trouble with openGL drawing, I have now gone the route that you suggested by skipping a real scrollpane and only drawing inside the NETWCanvasAWT. It actually is the smarter way it seems. Zooming is already working perfectly as well. My application users want to zoom in very strongly on their images to study details on pixelbasis. With the scrollpane setup, I needed to draw a huge Canvas/Panel inside the scrollpane then, which wasn't very nice performance wise. Now, by zooming in strongly, performance is awesome as well. I used to draw all image data using Java 2D which gave all sorts of problems and had much less performance obviously. So I am very happy with Jogl to enable OpenGL drawing in my application. Mabula Haverkamp https://www.astropixelprocessor.com/ |
Administrator
|
You're right, the drawing inside the viewport should be correct.
I'm going to have the same kind of problems as you because I need to do something similar in my first person shooter editor, there is a feature that allows to build 3D maps from possibly huge 2D images. Yes, Java2D seems to have inconsistent performance across platforms and sometimes your rendering looses the hardware acceleration for an unknown reason :s Maybe you can create your own fake scroll pane and your own scroll bars so that the result is still user friendly and with a canvas whose size depends on the container but not on the scroll.
Julien Gouesse | Personal blog | Website
|
Hi Julien,
Indeed, I am working on making a fake scroll pane. It's better for performance when you need to to zoom in on a very large image, which will happen in my application, because users can make huge mosaics. This weekend I did find a miscalculation in my coordinate systems, and reflecting on this, I think it might caused my initial issues with the scrollpane. I was zooming in with a factor of x and also had an xRatio, yRatio factor to keep the aspect ratio of the pixels fixed, these ratios were determined on the actual size of drawing the image relative to the scrollpane viewport. These xRatio and YRatio had the zoomfactor in them as well, so where I thought I was zooming in with factor x, I was actually zooming in with X^2 ;-( So I think I messed up myself in the end... I will not go back to the real scollpane setup, for performance reasons now, so in the end my error has pointed my in another direction with your help, which does deliver better performance in the end, so it's the better choice. Thank you for you assistance ;-) Kind regards, Mabula |
Administrator
|
You're welcome, I'll share my findings too if I find some spare time to work on this particular aspect.
Julien Gouesse | Personal blog | Website
|
Free forum by Nabble | Edit this page |