Journal #259850

I discovered that the overlay problem I reported earlier was caused by the Desktop Window Manager, which is responsible for compositing under Vista. The DWM expects applications to draw themselves into an off-screen surface, which it can use for compositing. The solution I found back then, which is to retrieve the DC on the primary surface, caused the locking of the primary surface, which forces the DWM to relieve control to the application and switch back to “Aero Basic” for the duration of the application.

So I came up with a more explicit solution this time:

Disabling the DWM

My DirectDraw Overlay Sample does not work on Windows Vista. It fails at the call to IDirectDraw7::UpdateOverlay, with the HRESULT DDERR_OUTOFCAPS. If you search online for that, you won’t find any meaningful results–only the explanation that this error occurs when the overlay capabilities are already maxed, i.e. the DDCAPS::dwMaxVisibleOverlays cap has already been surpassed.

In examining the issue, I noticed that AngelCode’s overlay sample works fine. After examining his code, the only difference in our initialization sequences is that he retrieves the device context–HDC–on the primary surface before showing the overlay. He does that because he draws manually to the overlay, and he uses GDI to figure out the format of the surface.

So, it turns out, the solution was to simply retrieve the device context on the primary surface and immediately release it before calling IDirectDraw7::UpdateOverlay.

With that problem out of the way, I’m now working on transforming my sample into a flexible, robust overlay library.