Multi Monitor Setup

[Gambit]

Display 0 might not be the primary display though. If displayed the numbered from the top left or clock wise order or something, 0 might be the top left monitor and say display 3 might be your primary. The point of sf::Display::getPrimaryID() would be to return the ID of the primary monitor so you dont have to query the OS to check yourself.

As for the ordering, because there are so many combinations of ordering and display x might be on the right of display y or might be on the left/top/bottom/etc is hard to work with. The fact that they dont have to be inline and you can have multiple displays of different resolutions is also a huge task to work with but only if you are tracking the positions of the monitors (Like sf::Mouse needs to know relative coordinates for the monitors).

[Pedro Bacchini]

What I suggested was a pattern to be followed in the implementation of the Display class to put 0 as the primary monitor regardless of screen organization, the organization of question are you discussing I'm not getting the message because the OS abstracts all this for us. Follow the OS.

[Gambit]

This is true for Windows but what about other platforms? Linux? Mac?. I have no experience in development in either of the latter and no experience with WinAPI to this degree. For Windows, perhaps a preliminary implementation could be made as a proof-of-existence type of thing, although I'm pretty sure everyone knows that its possible, it might be a good stepping stone for SFML.

Also, while Windows might track the order of the displays, how would you go about getting the relative positions between screens? You would need to have some sort of  center (0 0 0) (Which I'm guessing would be the primary display) and each display's position would be relative to that?

[Pedro Bacchini]

This is true for Windows but what about other platforms? Linux? Mac?. I have no experience in development in either of the latter and no experience with WinAPI to this degree. For Windows, perhaps a preliminary implementation could be made as a proof-of-existence type of thing, although I'm pretty sure everyone knows that its possible, it might be a good stepping stone for SFML.

The same goes for me we would have to evaluate this proposal to other platforms but already doing something for windows already is a first step as you said, I do not know how things here. The solution has to be complete for all platforms in this investigation phase?

Also, while Windows might track the order of the displays, how would you go about getting the relative positions between screens? You would need to have some sort of  center (0 0 0) (Which I'm guessing would be the primary display) and each display's position would be relative to that?

For example, let's say I make a game that uses this configuration:
Screen 1 the main left and right screen 2 hoping that this will be the configuration of the user, if it changes and puts the screen 1 from the right main screen and 2 on the left (because he can do it) the game is simply reversed . Because you supposes one configuration of the screens in the development and lets the user to course correct organization always leaving the observations correctly. Each window has a display and each has its point (0.0). Do not understand the question of the relative positions you could give an example.

[eXpl0it3r]

What are examples in which you need to know the display's physical location and ordering?

[Gambit]

You raised concern about where 0,0 would be with multiple displays.

Now that I think about it, the positioning of the screens (See Hapax's images for what I'm talking about) might not be a problem at all. If we can get the display that the window is on, we can work out relative coordinates for things like sf::Mouse based on that. I'm not sure how this idea will work if the window is displayed on multiple monitors though.

[thomas9459]

I don't really see the point of calculating a (0,0) for every monitor rather than using the actual screen positions, so that the top left corner of the primary monitor is (0,0) and all coordinates on any monitor are relative to this point. This is how it's done on basically every multi-monitor article/documentation/system that I've ever seen. So we would then just provide a sf::Display::getCount() and sf::Rect sf::Display::getRect(displayId) or similar. Then, if a user wants to, they can easily work out a (0,0) for each monitor if they need it. This also means that we don't need to (and wouldn't even make sense to) specify a display in functions like sf::Mouse::getPosition, which is much cleaner.

Also, we should keep in mind that if we are going to make SFML high-DPI aware (which becomes even more important in multi-monitor setups), we will need to report resolution in screen coordinates and not pixels.

[Hapax]

the top left corner of the primary monitor is (0,0) and all coordinates on any monitor are relative to this point.

The thing to remember here is that this will require possible negative coordinates for monitors to the left and/or above the primary's (0, 0) but that would only need to be so for the global desktop coordinates and not the monitor's local coordinates.
That is not to say that the implementation would not work.

I quite like the idea of just having rects defining where the screens are.

[Ixrec]

We should probably look at what the actual operating systems are doing before talking in detail about what the cross-platform API should be.

For Windows, it looks like almost everything will be under this page: http://msdn.microsoft.com/en-us/library/dd145071(v=vs.85).aspx
For Mac OS X, I think NSScreen is the place to start: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSScreen_Class/index.html#//apple_ref/occ/clm/NSScreen/screens
And for Linux I can find some useful XCB functions scattered around like this one: http://www.x.org/releases/X11R7.6/doc/libxcb/tutorial/index.html#ScreenCount

I also found an iOS page for handling "external displays": https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/WindowAndScreenGuide/Introduction/Introduction.html

I don't have time to read all of these pages myself, but one interesting thing I saw right away was a very clear answer about how multi-monitor screen coordinates work on Windows:

The primary monitor contains the origin (0,0). This is for compatibility with existing applications that expect a monitor with an origin. However, the primary monitor does not have to be in the upper left of the virtual screen. In Figure 1, it is near the center. When the primary monitor is not in the upper left of the virtual screen, parts of the virtual screen have negative coordinates. Because the arrangement of monitors is set by the user, all applications should be designed to work with negative coordinates. ... The coordinates of the virtual screen are represented by a signed 16-bit value because of the 16-bit values contained in many existing messages.

[Gambit]

Ill try and read through some of them today if I can. Hopefully they contain some sort of solution or insight to some of the problems here.