I'm working on getting fullscreen/resolution change capabilities working in my engine and I've encountered a problem that I can't seem to solve. I can change the screen resolution properly using the CGDisplay API but the windows from other applications are resized if I use a lower resolution than the current resolution.

I've seen that calling CGDisplayCapture() before resizing and CGDisplayRelease() after returning to windowed mode should prevent this from happening but it doesn't seem to have any effect other than putting up a 'shielding' window and preventing other applications from being used.

I think I might have figured out the issue - CGDisplayCapture() doesn't keep other windows from resizing when the computer has more than one display. I had been testing on my laptop with a second monitor connected, but when I tried it without the monitor, the application behaved as expected and kept other windows intact.

My hunch is that CGCaptureAllDisplays() would do the trick, though I don't want to steal the screen on the other displays.

No, they are not. In fact, the problem only shows itself when the other windows are not overlapping the un-captured display.

I did some more testing and it only seems to happen when using certain resolutions (1024x768 doesn't cause the issue but 1024x640 does). Even more curiously, the finder's windows are not affected in any case, only apps like Xcode.

I think I'm going to consider it a quirk that won't be an issue in most use cases - apps overlapping the un-captured displays seem to not be affected, plus it only resizes the other windows when using non-standard resolutions. Additionally, not that many people are going to be running multiple displays anyway.

I'm aware of that, but I still need the capability to change resolutions in my engine because it is a general-purpose tool. Do you know what the performance impact of that would be? I expect not much since everything stays in VRAM and blits are super fast on graphics hardware.

Exactly, the performance impact of the blit is minimal, and this way you don't have to disrupt the user's desktop experience in any way (command-tab still works, volume and brightness bezel graphics will display atop your app, etc.)

(Sep 5, 2012 09:25 PM)CarlSchissler Wrote: I'm aware of that, but I still need the capability to change resolutions in my engine because it is a general-purpose tool.

Sounds like you might be falling into the common pitfall of speculative coding. My experience has been that this leads to a lot of wasted effort, half-baked features, and messy code. The rule I try to follow is that nothing goes into my framework unless there's a known direct need for it, or my API would be fundamentally broken without it. I've tried to code an engine before without a clear enough idea of what I want to use it to build, and without having that to guide the design, it just went nowhere useful. Maybe your experience is different, but avoiding speculative coding has helped me quite a lot.