Multi Monitor Setup

[Ixrec]

I believe http://www.sfml-dev.org/development.php has all the information you need to get started with contributing, including a code style guide and contribution guidelines and whatnot.

[Pedro Bacchini]

thank you, I had already seen and one of the recommendations and discuss its possible contribution to the forum and why I took this post.

[eXpl0it3r]

If you want to help get this implemented, here are a few things to think about and discuss:

• What exactly does "Multi Monitor Support" mean?
• How should the API be designed or redesign to support this feature?
• Do all three major platforms (Windows, OS X, Linux) support this to the fullest extend?
• Does it apply to mobile platforms in the same way or can it be used for some similar functionality?

[Pedro Bacchini]

Excelent issues 

What exactly does "Multi Monitor Support" mean?

I believe it is support create windows in more than one motinor, and have control over what is drawn on each of them.

How should the API be designed or redesign to support this feature?

To this question as I have not much experience with API will have to investigate further so have a interesting solution will present it.

Do all three major platforms (Windows, OS X, Linux) support this to the fullest extend?

Yes believe this and a feature that extends to all operating table systems.

Does it apply to mobile platforms in the same way or can it be used for some similar functionality?

For mobile platforms I do not have idea of how it would be applied.

As there is minimal interest in this feature for the next day was more experience with the API and follow the discussions here.

It would be interesting also you guys get hold of this platform, which offers great potential.

https://sprout.hp.com/

[Ixrec]

I believe it is support create windows in more than one motinor, and have control over what is drawn on each of them.
...
Yes believe this and a feature that extends to all operating table systems.

I think we can be more precise than that.  Off the top of my head, we might want to support:

- Getting the current number of monitors
- Getting the valid fullscreen resolutions of all monitors
- Getting the current desktop resolutions of all monitors
- Creating a window on any monitor (as you said)
- Moving a window to any monitor, in addition to setting its position
- Getting/setting the monitor the mouse is currently on, in addition to its position

All of which are potentially complicated by the facts that:

- There is usually a "primary" monitor, which should probably be the "default" for most purposes
- A single window can occupy space on more than one monitor at a time.

I don't have a use case for multi-monitor support personally, and I suspect a lot of the scary corner cases are handled by OS magic, so I don't know how many of those things we actually care about.


My very brief googling on the mobile question implies that the only instances of mobile "multi-display environments" would be handheld gaming devices with two screens and projector phones.  I believe projector phones are dead, and we aren't planning on 3DS support anytime soon, so mobile might not be a problem.

[Gambit]

I think support for multiple displayswould be a pretty big project. I'm not really sure on how the primary monitor as default is an issue, nor the fact that a single monitor can take up more than 1 display.

This is sort of picky, but its important to note that a monitor isnt always what people mean (i.e if you are using a TV for your computer), so the topic should really be "Multiple display support".

As far as the implementation goes, I've never really used WinAPI and I've not developed on any other platforms but for the API, I have some suggestions.

I'm proposing to add a new class to SFML which might look something like this:

• size_t sf::Display::getDisplayCount()
• Vector2u sf::Display::getDisplayResolution(int [display from getDisplayCount])
• size_t sf::Display::getPrimaryDisplay() [returns the id of the primary display duh]

By extension, I'm also thinking something along the lines of the following methods should be added to sf::Window:

• void sf::Window::setDisplay(int [display from sf::Display::getDisplayCount])
• size_t sf::Window::getDisplay()

Alternatively, the methods could be added to sf::Display where the functions would take an extra paramter which would be the window object.

[Hapax]

I really like the idea of being able to have more control over multiple monitor/display set-ups, even if it one of the reasons why is a slightly selfish reason (I have multiple monitors).

- Getting the current number of monitors
- Getting the valid fullscreen resolutions of all monitors
- Getting the current desktop resolutions of all monitors
- Creating a window on any monitor (as you said)
- Moving a window to any monitor, in addition to setting its position
- Getting/setting the monitor the mouse is currently on, in addition to its position

Also, knowing the order and positioning of each monitor would be useful. e.g. monitor 1 may be on the right, or above etc..

This is sort of picky, but its important to note that a monitor isnt always what people mean (i.e if you are using a TV for your computer), so the topic should really be "Multiple display support".

Technically, a monitor is a way of monitoring output, so any display would count
Also, if a computer screen is displaying on a TV, the TV is often considered as "acting as a monitor".
Still, going with your Display class (I think 'display' might be a bit ambiguous and/or confusing), there's no need to include "Display" in the methods inside it.

• size_t sf::Display::getDisplayCount()
• Vector2u sf::Display::getDisplayResolution(int [display from getDisplayCount])
• size_t sf::Display::getPrimaryDisplay() [returns the id of the primary display duh]

would make just as much sense (if not more) if they were named:

• size_t sf::Display::getCount()
• Vector2u sf::Display::getResolution(int [display from getCount])
• size_t sf::Display::getPrimary() [returns the id of the primary display]

The last one could also easily be getPrimaryId() and probably should be. getPrimary (or getPrimaryDisplay) hints at returning the actual display rather than its index/ID.

[Hiura]

I've two questions to add to the reflexion list: What about current API? (Should coord system be changed for set/get mouse/window position? Would the coord system include a display parameter? ...) And what about distant displays? (e.g. AirPlay and other similar techs)

[Gambit]

I'm not sure why coordinate systems would have to change at all. This is purely window positioning on multiple displays. Objects are still rendered relative to a window object. As for the mouse, I dont see why it's positioning would need to change either. sf::Mouse::getPosition already has the ability to be passed a window object and return relative coordinates.

As for detached devices, I have no clue :|.

[eXpl0it3r]

Well if you have two monitors, where's the position (0, 0)? On monitor 1 or on monitor 2?

[Hiura]

And a third one for the road: How do virtual desktop play in the mix? (Do we want to support them or not? ...)

[dabbertorres]

Well if you have two monitors, where's the position (0, 0)? On monitor 1 or on monitor 2?

(0, 0) is the top-left corner of the leftmost monitor on your standard Linux extended desktop setup. If you have 2 1080p monitors, the top-left of the right monitor would be (1920, 0).

[Hiura]

Maybe that the case on (some) Linux, maybe it's the case on all OSes, but that doesn't mean SFML has to do it too... Remember: It's not because every body does something stupid that you have to do it too. Now, maybe this choice is not stupid, but it certainly isn't flawless: What about invalid position? (e.g. Three monitors in a L-shape, what is a position in the top right corner -- outside the L)

Also, if I have two monitors, on can be on top of the other one.

[Hapax]

My own setup is two monitors. The primary one is on the right and they are different resolutions (left one is higher resolution).
Also, you can (in Window - not sure about how/if other OSs do it) drag the display position into any position. I could have my monitors set up to be diagonal, for example. These sorts of setups would need to be allowed for when calculatin coordinates.
Here are three possible cases that could cause complications:

[Pedro Bacchini]

Well if you have two monitors, where's the position (0, 0)? On monitor 1 or on monitor 2?

(0, 0) is the top-left corner of the leftmost monitor on your standard Linux extended desktop setup. If you have 2 1080p monitors, the top-left of the right monitor would be (1920, 0).

I think so and not the clearest way, you first specify the monitor and then your position, each monitor has its (0,0).

Believe which monitor will be used must be passed by parameter for the creation of the window if it is not past is created in the default monitor. After this things already resolve themselves as the question of (0.0) that is would be a window for each monitor, I think so and simpler to extend the platform without compromising anything.

RenderWindow(VideoMode mode, const String& title,
         Uint32 style = Style::Default,
         const ContextSettings& settings = ContextSettings()
         Display display = getDisplay(0));

for example in case the mouse remains the same positions for returning positive if the mouse is in the right window that you want to verify and negative for others.

sf::Mouse::getPosition(window).x;

I think the sf::Display::getPrimary() method is redundant and can be created only as a friendly interface to getDisplay (0);

sf::Display::getResolution()

perhaps to maintain compatibility get resolutions that way

static VideoMode getDesktopMode(Display display = getDisplay(0));