OpenGL flickering due to scrollbar?


After using glut for years, I must now use windows functions to display an OpenGL context. Under WinXP, no problems the app runs fine. With Vista, the opengl display keeps filckering when I use my Pan function.

Before annoying you guys, I have read lots of posts/articles. the most important ones :

I have followed most of the advices in both:

  • I handle WM_ERASEBKGND in WndProc and do nothing
  • I do not use GDI drawings
    and it’s still flickering.

Introduction :

  • The main app is an mdi in WinForm
  • each mdi child (WinForm) as an OpenGL context.
  • each context is unique and doesn’t share anything with others.
  • each mdi child as scrollbars (V & H).
  • each opengl context use PFD_DOUBLE_BUFFER

The facts:

  • when I translate a view, the opengl display filckers with the window backgound (never refreshed and with random patterns).

I think this is due to the scrollbars which are in the same Form than the opengl context, because :

  1. the scene doesn’t flicker except with the Pan function
  2. the pan updates the scrollbars.
  3. when I use the scrollbars, the opengl display is covered by the same old dirty windows background.

You can reproduce this bug very easily : just create a simple form, add a control which touch the form border to make a scrollbar appear, and display something in the form.

Can anyone help me please ?

Do the following experiments:
Does it go away if you select a PIXELFORMAT which has PFD_SUPPORT_COMPOSITION not set? That should switch Aero off.
Or if you switch Aero off manually (Switch desktop to Windows Classic Theme).

If the answer to either is “Yes” you ran into the GDI on 3D HW accelerated window issue under Vista.
Most likely because the GDI drawn scroll bars are INSIDE your OpenGL window, overlapping its rendering.

You can also check if that’s the case with the Spy++ which comes with the Microsoft Visual Studio tools. If you click with the window finder into your OpenGL window and the frame the Spy tool renders includes the scrollbars, yes, you’re screwed.
BTW, The finder will render a rectangle with GDI to indicate the window you picked, that also will ruin the rendering.
Microsoft screwed GDI rendering under Vista royally.

With or without PFD_SUPPORT_COMPOSITION, it’s the same result. I use it just to follow OpenGL ARB advices, even if it does nothing in my case!

Apparently, it’s not…Why !?!..

With Aero disabled manually, it works, but I can’t expect users to switch off Aero every time they use my app.
I would like to avoid this : “Dear users, due to my incompetence, you have to turn off Aero” :wink:

If I remove the scrollbars everything runs perfectly, so as you said, it seems to come from the overlapping between windows widgets and the opengl context. It may be the only way to avoid flickering…

But, before I give up, just a noob question about windows context handling (perhaps related to my issue):
When the opengl context is created, I save the HDC and HGLRC in a member, use them every time I display something with OGL (wglMakeCurrent)and release them only when the app is closed. I saw code samples where the HDC is an argument of the draw function and its released after each SwapBuffer. What is the good practice ?

Actually I misremembered the newsletter. It says:
“Create an OpenGL context using a pixelformat with GDI support (PFD_SUPPORT_GDI flag set). As this flag is mutually exclusive with PFD_SUPPORT_COMPOSITION, this will disable Aero for the lifetime of the current process.”

Make sure you actually got a pixelformat where these flags are what you wanted by using DescribePixelFormat() on the pixelformat index and verify the dwFlags field you got.

What OpenGL implementation are you running?

Using PFD_SUPPORT_GDI doesn’t change anything.

I wondered why and following your advice, I tested the pixel format with DescribePixelFormat.
I found something weird : with or without PFD_SUPPORT_GDI/PFD_SUPPORT_COMPOSITION, I always get the same format :
the flags I wanted : DOUBLE_BUFFER | SUPPORT_OPENGL plus PFD_SUPPORT_COMPOSITION and another flag I didn’t set : DRAW_TO_WINDOW…

Maybe Windows force PFD_SUPPORT_COMPOSITION ? But the newsletter says the contrary…

I also used Spy++. Actually, the scrollbar and the ogl context are in the same frame. :’(.

glGetString(GL_RENDERER) just gave me my driver name :
“Radeon X1300/X1550 Series”

Correct me if i am wrong, but the only way to bypass my issue without using PDF_SUPPORT_GDI is “simply” to delete the scrollbars.

Do you have an opinion about the end of my last post ?

Did you use ChoosePixelFormat()?
That thing is bugged and ignores most of the interesting bits.

Enumerate the pixelformats yourself with DescribePixelFormat().
It returns the number of pixelformats available, then just iterate through them and see if the Radeon driver actually reports pixelformats with dwFlags matching the new Vista driver caps. If not, that would be a driver problem. This worked fine for me on NVIDIA.

If you could put the scrollbars to lie outside the client region of the OpenGL window, maybe that would work. No clue how the forms handle these things.

About the HDC handling: In former times there were limited amounts of HDCs available (actually only four at the same time under Windows 3.1 :sick:). With the Win32 API the most efficient for small demos with only one context is to

  • Do a GetDC() during WM_CREATE and keep that somewhere,
  • Create and make the OGL context current once,
  • No need to call wglMakeCurrent on WM_PAINT again
  • Do not use BeginPaint-EndPaint in WM_PAINT because that always gets you a HDC and it may actually change unless you have CS_OWNDC in you window class,
  • Use ValidateRect(hwnd, NULL) instead to clear the paint region after you have handled WM_PAINT.
  • Do wglMakeCurrent(NULL, NULL) and OGL context deletion and ReleaseDC() when you quit the app.
    That’s how I do samples and small test apps.

Indeed, I used ChoosePixelFormat.

To solve the flickering, I chose to delete the scrollbar. Most 3D/CAO apps don’t use them to move in the viewport. I think putting scollbars outside the opengl window would work.

Thanks a lot for all your advices and your precious help !

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.