Clear status about GLCanvas without animator

Hi all,

Like other users I notice that a GLCanvas does not display anything unless an animator is used to manage the rendering loop.

As far as I know, this used to work fine with Jogl1 and even with previous builds of Jogl2. For some application, it is more desirable to not use an animator, because the scene does not change on a time basis but only when the users interacts with the application.

What is confusing about this issue is that:
- this seems to work for some users but not for all
- some people already asked whether using a GLCanvas without an animator is a supported feature or not but the answer looks unclear to me so far. If it is supported, I guess the bug will be fixed. Otherwise, it won't, as it is definitely not a bug.

I did not find any bug related to that issue in bugzilla. Therefore, I would be glad to know about the official status. I never used an animator in my app so far and I would like to know whether or not I have to change my design.

Thanks a lot,
-Cyrille

Hi!

It works, you only have to call explicitly the display method of your GLAutoDrawable instance. Please read the documentation:
"This routine may also be called manually for better control over the rendering process."

What is wrong with this?

I tried to call display() explicitly but it doesn't work.

In the sample application below, the canvas appears yellow at startup (its background color) while I expect it to be red (OpenGL clear color). If I call display() everytime the canvas is resized, the canvas flickers between yellow and red during the resize operation and randomly ends yellow or red.

package GLSLTest;

import java.awt.Color;
import java.awt.Component;
import java.awt.Frame;

import javax.media.opengl.GL;
import javax.media.opengl.GL2;
import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLCapabilities;
import javax.media.opengl.GLEventListener;
import javax.media.opengl.GLProfile;
import javax.media.opengl.awt.GLCanvas;
import javax.swing.BoxLayout;

public class Main
{
        static CanvasListener listener = new CanvasListener();

        public static void main(String[] args)
        {
                GLProfile.initSingleton();

                GLProfile profile = GLProfile.getMaxFixedFunc();
                GLCapabilities caps = new GLCapabilities(profile);
                GLCanvas canvas = new GLCanvas(caps);
                canvas.setBackground(Color.yellow);
                canvas.addGLEventListener(listener);

                Frame topLevelFrame = new Frame();
                topLevelFrame.setLayout(new BoxLayout(topLevelFrame, BoxLayout.Y_AXIS));
                topLevelFrame.add(canvas);
                topLevelFrame.setSize(400, 300);
                topLevelFrame.setVisible(true);

                // Animator animator = new Animator(canvas);
                // animator.start();

                canvas.display();
        }
}

class CanvasListener implements GLEventListener
{
        @Override
        public void display(GLAutoDrawable arg0)
        {
                GL2 gl = arg0.getGL().getGL2();
                gl.glClearColor(1.0f, 0.0f, 0.0f, 0.5f);
                gl.glClear(GL.GL_COLOR_BUFFER_BIT);

                System.out.println("display");
        }

        @Override
        public void dispose(GLAutoDrawable arg0)
        {
        }

        @Override
        public void init(GLAutoDrawable arg0)
        {
                Component canvas = (Component) arg0;
                System.out.println(canvas.getSize().toString());
        }

        @Override
        public void reshape(GLAutoDrawable arg0, int arg1, int arg2, int arg3, int arg4)
        {
        }
}

Your build is too old, really, completely obsolete, GLProfile.initSingleton() does not exist anymore. Please use at least the build 200.

Ok, I'll update my build, then...

BTW, its a pretty good news that Jogl got rid of GLProfile.initSingleton() ;)

Thanks for your help.
-Cyrille

It is not completely solved, sometimes I have to call GLProfile.initSingleton(true) or GLProfile.initSingleton(false) but it is very rare.

On Friday, November 19, 2010 14:12:28 Cyrille [via jogamp] wrote:
Should work again (for a longer while).

Wade confirmed it, and I see it being repainted in the unit test cases.

Please confirm with the latest archived builds,
add a bug report to it.

Sure, it should work :)

~Sven

>Sure, it should work :)
Thanks Sven for your reply. This is what I call "a clear status" !

I'll give it a try with the latest build as soon as I have time for it. And I'll tell here what happens.

Thanks again to everyone.
-Cyrille

Hi,

I tried the code sample above with the latest autobuild I found : jogl-2.0-b229-20101123-windows-i586

It works better, not perfectly though. The canvas displays the scene but when resizing the frame, it still flickers. It randomly ends displaying either the scene or the canvas' component background color.

I do *not* call display() explicitly because I expect the canvas to call it whenever needed (during the repaint operation, for instance). So why does it flicker and display alternately its scene or its background?

-Cyrille

On Tuesday, November 23, 2010 15:48:32 Cyrille [via jogamp] wrote:
>
> Hi,
>
> I tried the code sample above with the latest autobuild I found : jogl-2.0-b229-20101123-windows-i586
>
> It works better, not perfectly though. The canvas displays the scene but when resizing the frame, it still flickers. It randomly ends displaying either the scene or the canvas' component background color.
>
> I do *not* call display() explicitly because I expect the canvas to call it whenever needed (during the repaint operation, for instance). So why does it flicker and display alternately its scene or its background?
>

I remember something like this in regards to GLCanvas,
ie we try to remove the 'background erase', which may not work all the time
on different platforms.

Please follow proper bug reporting:
  http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

Please read the 'junit test' part carefully, since that guarantees we quickly
can verify this. Sure we need the other information as well.

So I guess, this will become the 'Flickering GLCanvas' bug.
NEWT works fine I assume.

Thank you.

~Sven

> -Cyrille

You would get a more consistent behavior by disabling auto swap buffer mode and calling display() by yourself.

> Please follow proper bug reporting:
>  http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

Sure, done. I filed bug 439. I did not write a JUnit test case as this test requires some user interaction anyway. Hope you'll be comfortable enough with that.

On Friday, November 26, 2010 14:06:49 Cyrille [via jogamp] wrote:
>
> > Please follow proper bug reporting:
> >  http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing
>
> Sure, done. I filed bug 439 . I did not write a JUnit test case as this test requires some user interaction anyway. Hope you'll be comfortable enough with that.

I am already on it :)

Actually it's not a bug you could file towards JOGL,
but more details on my response. Your drops/attachments were qualified (log).

~Sven

On Friday, November 26, 2010 14:06:49 Cyrille [via jogamp] wrote:
>
> > Please follow proper bug reporting:
> >  http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing
>
> Sure, done. I filed bug 439 . I did not write a JUnit test case as this test requires some user interaction anyway. Hope you'll be comfortable enough with that.

btw .. you could have simply wrote some loops with setSize on the GLCanvas :)

next time ..

> btw .. you could have simply wrote some loops with setSize on the GLCanvas :)

Damned... The point is that I tried to code a JUnit4 test case and I was planning to use the trick you mentioned. But for some reason, at the end of my @Test method, the Frame containing the canvas disappears immediately. I could not figure out why. The reason certainly resides in the fact that I am quite a newbie to this 21st century's way of testing. If you have a tip to work around this, tell me and I'd be glad to fulfill all of the responsible-bug-reporter commitments ;)

Thanks for looking into it so quickly, anyway. That's the great point.
-Cyrille