Supporting multi-monitors

Question

I want to provide multi-monitor support in my application.

In the past I have had the simplistic view that multi-monitor support is simply the lack of open multi-monitor related bugs. If it seems to work on a multi-monitor setup, then it supports multi-monitors, right?

But I would like to create some clear requirements about this.

What are the basic requirements I need to adhere to, in order to satisfy most users' expectations so that they might say "yes this application supports multi-monitors"?

For example an obvious requirement is that all windows/messageboxes/tooltips etc must open on the same monitor that the application is on. And any children of those windows must open on the same monitor as their parent.

Can you think of any more? Are there any guidelines about this anywhere?

Answer 1

It absolutely drives me crazy if I try to maximize a window and it insists on being docked in the 'main' monitor. Most modern windows apps don't have this problem, but I specifically remember RAdmin 2.x doing this.

Answer 2

• if the application was last used in a multi-monitor setup, and started up a second time with none of the additional monitors plugged in, make your application sense this and more all boxes and working areas back into the main screen.

(Eclipse doesn't do this and it annoys the hell out of me)

Answer 3

What makes me very happy is an application that remembers where all of its windows are (be they on the main monitor or second monitor) and re-displays everything in the same layout when I start up the application.

Answer 4

I always thought this was an OS responsibility. It seems that way on the Mac. Alas, I've run into lots of apps in Windows that don't behave very well on dual monitors, though I've tended to blame that on the video card.

My biggest complaint are apps that insist on using an MDI interface only. MDIs are great if you have limited screen space but get quite annoying when you actually have lots of screen space and want floated pallets/documents separate from each other.

Answer 5

Couple of nasties to watch out for from personal experience (with GDI and Direct3D9 anyway):

• When the two monitors have different bit depths, and the user expands the window to cover both monitors or drags it from one to the other... well it can get ugly if your app wasn't expecting it. Used to be much more of a headache back when systems might mix 8-bit palletized displays with higher bit-depth RGB ones (although be aware that such configurations are still out there for certain specialized applications).

• Direct3D windows created on one "D3D device" may need attention if you drag them to another display (wholly or partially). Depending how you set up the device, windows either displays nothing on the other display, or does display content but with a massive amount of CPU-processing overhead (enough to kill high frame rates). (This was true on XP anyway).