reibisch's picture

GLControl/GameWindow disables Aero under Win7

Project:The Open Toolkit library
Category:bug report

This is a report for rev. 3069 (1.x-dev) under Windows 7 64bit.

In short, it appears that the current development version disables Aero during context creation (screen flicks to black then restores with Aero disabled). Destroying the context re-enables Aero.

Current hardware is NVIDIA Quadro 2000 - 1024mb patched to the latest drivers ( -- 25 May 2011).

Additional information from this forum thread (which implies that it was occurring by 3064).


Comment viewing options

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


Can you please post the GraphicsMode that is in use when this happens? I.e. create the GLControl and post the results of GraphicsContext.GraphicsMode.ToString() here.

the Fiddler's picture


Status:open» need info
reibisch's picture


Unfortunately I just left town for vacation this afternoon and won't be back at work until mid-next week. The information is sitting in a text file right on my desktop, too! (I meant to include it in the bug report)

I just checked my home system, and it seems to work without issue -- though I'm running substantially older drivers here and have a much older card (an NVIDIA GTX 275).

yehiyam's picture


I just switched to the December 22 2011 nightly build, from version 1.0 and noticed the same problem. I see that this bug is in needInfo state, so I will try to revive it.
I'm working on Windows 7 enterprise, service pack 1 x64.
GPU: Nvidia quadro 4000 driver version 285.58.

As per your request, I've ran the example browser (ImmediateMode example) and this is chosen graphics mode:
Index: 251, Color: 24 (8880), Depth: 24, Stencil: 0, Samples: 0, Accum: 64 (16161616), Buffers: 2, Stereo: False.

With version 1.0 I get:
Index: 7, Color: 24 (8880), Depth: 24, Stencil: 0, Samples: 0, Accum: 64 (16161616), Buffers: 2, Stereo: False.

c2woody's picture


251 has WGL_DRAW_TO_WINDOW set to FALSE which would be quite strange.

Diaren's picture


Just noticed this myself, and came across this thread on osdir:

< quote >
I've also been experiencing the fullscreen issue with nVidia cards on
Windows 7. Just wanted to let you know that I found a workaround.
When creating the OpenGL context, I changed the swap method from
WGL_SWAP_EXCHANGE_ARB to WGL_SWAP_COPY_ARB. This completely solved the issue
for me.
Hopefully nVidia will fix their drivers in a future release.

IMHO He has found the workaround and but also the source of the problem. I
just checked his solution and it simply works.
So I think that with Aero DWM not having front buffer but internal Direct3D
texture, its quite understandable why COPY works better than EXCHANGE. Its
hard to understand though why NvIdia drivers suggest EXCHANGE in
ChoosePixelFormat when it does not work correctly. Btw I checked with
DescribePixelFormat if the returned PixelFormat is compatible with
PFD_SUPPORTS_COMPOSITION . And yes, returned description structure reports
this compatibility. So this whole issue looks weird and definitely points to
the drivers as the source of the problem. The drivers have the option to
return PixelFormat with SWAP_COPY method but it keeps returning

< /quote >

The required attributes and values are:

I'm not sure what the best way to update the source (OpenTK\Platform\Windows\WinGraphicsMode.cs) is, but if nothing happens here then I'll provide a quick hack of some sort in the near future.

Diaren's picture


Status:need info» confirmed

After reading the information in my above post, I modified the source as below as a quick hack for myself while developing. Although this fixes the issue, according to this thread it only seems to apply to windows aero and nvidia drivers, so the issue is not related to OpenTK.
I can't see a suitable fix besides adding an option to the API and leaving it up to the developer to decide on whether to enforce the use of the SwapMethodArb attribute.

Updating version 1.1.749.3121 (2012-01-20)

diff --git a/OpenTK/Platform/Windows/WinGraphicsMode.cs b/OpenTK/Platform/Windows/WinGraphicsMode.cs
index 8eecdf6..84c75fb 100644
-- a/OpenTK/Platform/Windows/WinGraphicsMode.cs
++ b/OpenTK/Platform/Windows/WinGraphicsMode.cs
@@ -228,6 +228,7 @@ namespace OpenTK.Platform.Windows
                    (int)WGL_ARB_pixel_format.SupportOpenglArb, 1,
                    (int)WGL_ARB_pixel_format.DrawToWindowArb, 1,
                   (int)WGL_ARB_pixel_format.SwapMethodArb, (int)WGL_ARB_pixel_format.SwapCopyArb,
                    0, 0
AMagill's picture


I tried the above approach, and it didn't seem to do any good on my system.. Aero would still get disabled every time. I've noticed, though, that GetModesARB() would always yield quite a few seemingly identical modes. There must be some other property of the mode we're not checking that's causing the problem.
It seems to me that the video drivers always assign the smallest indices to the most compatible modes. So given multiple modes with seemingly identical properties, it makes sense to always prefer the one with the smallest index. Since GraphicsModeComparer::Compare() ignores indices, though, these identical-looking modes would wind up being sorted in an undefined order.
I was able to solve the problem for myself by having GraphicsModeComparer::Compare() also compare indices (as the last, weakest point of comparison), so that smaller indices would be sorted first.

AMagill's picture


I propose this change, implementing my previous post suggesting that OpenTK prefer graphics modes with the smallest index as the last point of comparison between modes. I believe it fully solves this issue.

--- GraphicsModeComparer.cs.orig
+++ GraphicsModeComparer.cs
@@ -55,7 +55,10 @@
             result = x.Buffers.CompareTo(y.Buffers);
             if (result != 0)
                 return result;
-            return x.AccumulatorFormat.CompareTo(y.AccumulatorFormat);
+            result = x.AccumulatorFormat.CompareTo(y.AccumulatorFormat);
+            if (result != 0)
+                return result;
+            return ((int)(x.Index)).CompareTo((int)(y.Index));
AndyKorth's picture


Well the suggested fix works on my machine. If anyone else on Windows 7 can confirm it fixes this problem, I can port it to my main branch.

For now I've got it on this branch so it doesn't get lost or forgotton: