在我把这个减less到一个合理的例子之前，我希望以前有人遇到过这个问题，并且能够解决这个问题。
我有一个32位的基于C的应用程序，每个窗口使用一个OpenGL上下文，所有的上下文和窗口设置相同。 请求的像素格式是32位颜色，alpha，深度缓冲区，加速。 一切工作在Windows 2000和XP上完美无缺。
一切都在Vista和7上完美运行，直到第33个窗口/上下文对被创build。 创build窗口没有错误，创build上下文没有错误，使上下文当前没有错误，绘图不会产生错误，SwapBuffers不会产生错误。 然而，OpenGL上下文无法产生任何输出，Aero的窗口是白色的，它们没有绘制的经典模式，只是屏幕上的垃圾。 杀死DWM并不能解决问题，尝试不同的像素格式（单个缓冲区，差异深度等），PFD_SUPPORT_COMPOSITION不能解决问题。 这是在Vista / 7的许多不同的机器，从来没有XP。
我可以glReadPixels后缓冲区，他们是正确的像素。 使用相同的上下文渲染到一个pbuffer工作正常，渲染到> 32 pbuffers是好的。
如果我自由工作在屏幕上下文/窗口，非工作窗口再次开始工作。 就好像Vista / 7只是在32个窗口在屏幕上停止显示OpenGL渲染一样。
如果像素格式描述符包含PFD_SUPPORT_GDI，则一切正常，但使用的软件渲染器是不可接受的。
我想知道这是否是Vista / 7中的操作系统限制或驱动程序限制。 感谢您的任何见解。
限制是特定于实现的，你所能做的就是在通用硬件上运行一些测试。
我自己做了一些测试，事实证明，GeForce显卡的极限是非常高的（甚至可能没有限制）。 对于台式机Quadro来说，有128个上下文的限制能够正确重新绘制，程序能够创建128个更多上下文而没有错误，但是窗口包含垃圾。 我没有使用PFD_SUPPORT_GDI。
在ATi Radeon 6950上更加有趣，在＃105窗口停止了重画，并且创建渲染上下文＃200失败。
如果你想自己尝试，可以在这里找到程序： Max OpenGL上下文测试 （有完整的源代码+ win32二进制文件）。 也许你可以看看代码并追查罪魁祸首，会非常感兴趣的听到它。
这就是结果。 一条建议 – 尽量避免使用多个上下文。 在多个监视器上运行的应用程序中可以理解多个上下文，但是单个监视器上的应用程序应该使用单个上下文。 上下文切换很慢。 而这还不是全部。 OpenGL窗口与另一个窗口重叠的应用程序需要硬件剪切区域。 GeForce上有一个硬件剪裁区域，Quadro有八个或更多（CAD应用程序通常使用与OpenGL窗口重叠的窗口和菜单，与游戏相比）。 如果需要更多的区域，渲染会回落到软件 – 同样，有很多的OpenGL窗口（上下文）不是一个好主意。
请注意，这与您可以同时创建多少个OpenGL渲染上下文是否有限制？