OpenGL sync

[kamano]

Dear All, I am still a naive to SGI and OpenGL programming, therefore, I would like to have your advice.
When I run my OpenGL program (to present .png images on display, or draw a small square with different intensities for display calibration), I noticed some "flicker" appear on the display screen.It is not visible in normal IRIX desktop, so I wonder if there may be a problem in synchronization in my code. (I think) I did not specifically put any command in my program to "sync" or interpret the frame rate of the display.
In main(), I just put something like,
glutInitDidpslayMode(GLUTRGBA| GLUT_DOUBLE| GLUT_DEPTH);
glutInitWindowSize(wx, wy);
glutInitWindowposition(0, 0);
window = glutCreateWindow("")
InitGL(wx, wy);
glutDsiplayFunc(DrawGLScene);
and mouse and keyboard functions....etc

Should I include any other command here? Or, OpenGL or glut can adjust automatically whatever the display setting is?
Many thanks.
Or, I also wonder if the display may be faulty.
(running Fuel with IRIX 6.5.30m.)

[figgles]

Since nobody else has replied, I thought I'd go ahead and give you a few points in the right direction.

If you are running an Octane(2) with a V6 card, the flickers will likely be present in any and all OpenGL programs (I don''t have a link off hand, but 1280x1024 is only supported @ 96Hz, and the 60 Hz configuration causes flickering). If yours is the only program with this issue, then your program is likely buggy. Since you are using GLUT rather than straight GLX, I would try copying the simplest possible example programs from the Internet and trying to verify their behaviors.

[squeen]

With OpenGL, you may possibly see "tearing" (a non-sync of the framebuffer update and the display rasterization), which will appear as a brief horizontal split, but no "flicker" with any GLUT app unless there is a hardware problem.

There is some way to also prevent tearing on IRIX as well (or it may do it automatically), but it escapes me right now.

[kamano]

There is some way to also prevent tearing on IRIX as well (or it may do it automatically), but it escapes me right now.

Is the "tearing" a kind of moire-ish pattern?
Would you a bit more information about the "some way" on IRIX?
Thank you so much for your help.

[squeen]

Tearing is when the rastering of the display device (montior) is not in sync with the update of the OpenGL buffer. Double buffering in OpenGL usually helps this problem, but on NVIDIA cards under Linux there is an option to "turn on" VSync. Turning it on forces glxSwapBuffers (for double buffering) to only occur in-between the monitor's refreshes (@ ~60Hz).

What happens is that all display scan lines below the "tear" will have the information (GL primitives) drawn in the position they were at the preceding frame, while the information above the "tear" will be in the current frame position.

What I can't remember is if IRIX OpenGL is always in a VSync-like mode when it double-buffers. I think "yes".

Does that help?

[ShadeOfBlue]

What I can't remember is if IRIX OpenGL is always in a VSync-like mode when it double-buffers. I think "yes".

I also think VSync is always enabled.

I remember reading something about it on usenet a long time ago -- IIRC, someone asked why the FPS counter never goes above the monitor's refresh rate and the answer from an SGI employee was that it's because vsync is always enabled.

[kamano]

What I can't remember is if IRIX OpenGL is always in a VSync-like mode when it double-buffers. I think "yes".

I also think VSync is always enabled.

I remember reading something about it on usenet a long time ago -- IIRC, someone asked why the FPS counter never goes above the monitor's refresh rate and the answer from an SGI employee was that it's because vsync is always enabled.

So, could I just clarify whether, if the timing in the program may not match to the refresh rate of display, the IRIX OpenGL automatically adjust the timing not to conflict with the display, that is, wait until the beam scan go through end of the frame?

Even if we want to present an image for 1 s (1000ms), the real presentation will be
a bit shorter or longer, strictly speaking? (16.7ms difference with 60Hz frame rate?)

[ShadeOfBlue]

I think so, since drawing is synced to the refresh rate of the monitor.