stenio's picture

GLControl strange behaviour on tab switching

Hello,

I have a strange "flickering" problem with GLControl. I have 3 tab pages of a System.Windows.Forms.TabControl. The first and the second pages are filled with a GLControl while on the third page there is a MonthCalendar (or a Button or something else). Consider this code:

public partial class Form1 : Form {
        public Form1() {
            InitializeComponent();
        }
 
        private void glControl1_Paint(object sender, PaintEventArgs e) {
            // This delay makes the problem evident.
            System.Threading.Thread.Sleep(500);
            glControl1.MakeCurrent();
            Gl.glClear(Gl.GL_COLOR_BUFFER_BIT);
            glControl1.SwapBuffers();
        }
 
        private void glControl2_Paint(object sender, PaintEventArgs e) {
            // This delay makes the problem evident.
            System.Threading.Thread.Sleep(500);
            glControl2.MakeCurrent();
            Gl.glClear(Gl.GL_COLOR_BUFFER_BIT);
            glControl2.SwapBuffers();
        }
 
        private void glControl1_Load(object sender, EventArgs e) {
            Gl.glClearColor(0, 0, 0, 1);
        }
 
        private void glControl2_Load(object sender, EventArgs e) {
            Gl.glClearColor(0, 1, 0, 1);
        }

If I switch from the first page to the second, the third, the second and to the first again I see the calendar as a sort of background before the first control is painted. I suspect that the tab control buffering is conflicting with that of the SimpleOpenGlControl in some way.

Do you have any ideas?

Thanks,
Stenio


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

The contents of an OpenGL context are undefined when the calendar is shown. In your example, the contents become defined again, when SwapBuffers() executes. The longer this takes, the longer the garbage will be shown.

This might be fixable by using a pixel format with swap copy instead of swap exchange semantics. You can test this theory by adding the following lines to WinGLContext.cs, line 118 and recompiling OpenTK:

attributes.Add((int)WGL_ARB_pixel_format.SwapMethodArb);
attributes.Add((int)WGL_ARB_pixel_format.SwapCopyArb);

If this helps, it would be possible to add this as an option and enable it by default for GLControl.

stenio's picture

Hi Fiddler,

I've just tried but the result is the same :(

Below the output window log. I don't know if it could help.

GraphicsMode.Default = Index: , Color: 32 (8888), Depth: 16, Stencil: 0, Samples: 0, Accum: 0 (0000), Buffers: 2, Stereo: False
Detected configuration: Windows / .Net
Loaded opengl32.dll: 8791549673472
Eccezione first-chance di tipo 'System.DllNotFoundException' in OpenTK.dll
Creating GraphicsContext.
GraphicsMode: Index: , Color: 32 (8888), Depth: 16, Stencil: 0, Samples: 0, Accum: 0 (0000), Buffers: 2, Stereo: False
IWindowInfo: Windows.WindowInfo: Handle 919180, Parent (null)
GraphicsContextFlags: Default
Requested version: 1.0
DisplayDevice 1 (primary) supports 225 resolutions.
[WGL] Creating temporary context to load extensions
Setting pixel format... [WGL] ChoosePixelFormatARB not supported on this context
2
OpenGL will be bound to window:919180 on thread:10
Setting pixel format... 3
Using WGL_ARB_create_context... success! (id: 65537)
Destroying window: Windows.WindowInfo: Handle 591760, Parent (null)
Bindings loaded in 96.3199 ms.
Il thread 0x14f8 è terminato con il codice 259 (0x103).
Creating GraphicsContext.
GraphicsMode: Index: , Color: 32 (8888), Depth: 16, Stencil: 0, Samples: 0, Accum: 0 (0000), Buffers: 2, Stereo: False
IWindowInfo: Windows.WindowInfo: Handle 460736, Parent (null)
GraphicsContextFlags: Default
Requested version: 1.0
OpenGL will be bound to window:460736 on thread:10
Setting pixel format... 3
Using WGL_ARB_create_context... success! (id: 131072)
Sharing state with context 65537: success!
Bindings loaded in 16.9626 ms.
Disposing context 65537.
Disposing context 131072.

Thank you anyway,
Stenio