SFML community forums

General => General discussions => Topic started by: Foaly on July 30, 2014, 12:49:42 am

Title: Multi Monitor Setup
Post by: Foaly on July 30, 2014, 12:49:42 am
Hello there!
I think I already mentioned it in some other post, but I often have a setup, where I have a normal pc/laptop with a control window and a projector as a second screen with a fullsreen window, that displays the graphics.
There was a topic recently about multi monitor support and selecting the fullscreen monitor, but it hasn't gotten much attention. Since designing a clean and simple API for this seems tricky (things like fullscreen windows streching over multiple monitor or vertical setups have to be considered) and the process hasn't even started; I thought I'd make this suggestion.
Right now with SFML it is impossible to select the monitor for the fullscreen window. If a SFML window is created with the fullscreen flag it always goes into fullscreen on the first monitor. I think it would be way better to let the window go into fullscreen on the monitor it currently resides in. That would offer a nice way for some workarounds till a good design is found.
Right now I am using this on windows to get a window into fullscreen on the second monitor:
sf::RenderWindow window(sf::VideoMode::getFullscreenModes()[0], "Window", sf::Style::Fullscreen);

// width of first monitor is 1280, so move the window onto the second monitor
window.setPosition(sf::Vector2i(1300, 0));

MONITORINFO mi = { sizeof(mi) };

HWND hwnd = window.getSystemHandle();

// get the coordinates of the monitor the window is currently in
GetMonitorInfo(MonitorFromWindow(hwnd, MONITOR_DEFAULTTOPRIMARY), &mi);

// move the window
SetWindowPos(hwnd, HWND_TOP,
             mi.rcMonitor.left, mi.rcMonitor.top,
             mi.rcMonitor.right - mi.rcMonitor.left,
             mi.rcMonitor.bottom - mi.rcMonitor.top,
             SWP_NOOWNERZORDER | SWP_FRAMECHANGED);
 
Other people had similar setups/problems, so I think integrating something along those lines into the switchToFullscreen method would be a very nice addition.
Title: Re: Multi Monitor Setup
Post by: Strelok on July 30, 2014, 01:03:40 am
I think the main problem is maintaining a common API for all the platforms and probably there aren't enough users to consider the effort. Just my 2 cents.
Title: Re: Multi Monitor Setup
Post by: Foaly on July 30, 2014, 10:36:49 am
Well... that's exactly my point :D
The topic seems to be rather complicated and it doesn't have a high priority since not a lot of people have requested it. (altough I remember a couple forum threads and there is even a issue on the tracker (https://github.com/SFML/SFML/issues/188))
Thats why I suggested to let the window go into fullscreen on the monitor its currently in. This offers a simple way to select the monitor for fullscreen, by simply moving the window to the correct monitor and then let it go fullscreen.
Title: Re: Multi Monitor Setup
Post by: Hapax on July 30, 2014, 01:41:56 pm
I'd quite like to see this too but I don't find it majorly important. The issue on the tracker that you linked said it is planned anyway. The problem here is that you've now posted code that proves that SFML might not needed to be altered :P
Title: Re: Multi Monitor Setup
Post by: Ixrec on July 30, 2014, 08:03:20 pm
Quote from: Hapax on July 30, 2014, 01:41:56 pm
The problem here is that you've now posted code that proves that SFML might not needed to be altered :P

It's Windows-specific code, so it doesn't prove that at all.
Title: Re: Multi Monitor Setup
Post by: Hapax on July 30, 2014, 10:25:54 pm
I think "prove" was used a bit strongly, sorry. I did mean, however, that it 'suggests' ( :P ) that SFML is not in the way of being able to do it so it doesn't necessarily need to add in the functionality as it can be achieved alongside SFML. (unlike menues, unused events etc. *cough*)
I would like to just point out that I think the multi-monitor stuff should be in SFML but it's obviously agreed anyway as they're planning on implementing it  :)
Title: Re: Multi Monitor Setup
Post by: Foaly on July 31, 2014, 01:13:56 am
Haha good! Then we are on the same page :D Because that is exactly what I said in my first post.
I know it's planned to be implemented, but if you take a look at the ticket it hasn't been touched in the last 2 years. Also this issue does not have a very high priority, since right now there are things more important (like finishing the moblie ports etc.)
Thats why I suggested to let the window go into fullscreen on the current monitor instead of statically picking the first one. That would offer a clean workaround untill a proper API has been developed.
Title: AW: Multi Monitor Setup
Post by: eXpl0it3r on July 31, 2014, 02:00:47 pm
I'm not sure about the details, but there are two points one should keep in mind:



Maybe I make it sound worse than it actually is, but as I said, I don't know the details. ;)
Title: Re: Multi Monitor Setup
Post by: Foaly on July 31, 2014, 05:41:36 pm
Hmm those are actually good points.
It seems as if you are right about the first point. I don't think that many parts need to be refactored, but it might be more than this one method. For example the getFullscreenModes() method also only querys the first monitor for valid modes. I noticed this, because the code I posted doesn't work 100% as you'd expect it. It only makes the window fill the whole screen of the second monitor, but it keeps the video mode from the first monitor (meaning the output is askewed, because my second monitor has a different aspect ratio)
About the second point. I'm not an expert on this, but what I understood from my reseach is, that windows spanning over mutiple monitor and resources shared between graphic cards are handled by the operating system (on windows at least).
Title: Re: Multi Monitor Setup
Post by: Jesper Juhl on July 31, 2014, 05:47:56 pm
Also keep Xinerama (http://en.m.wikipedia.org/wiki/Xinerama) in mind...
And in the future, how will this work with Wayland (http://wayland.freedesktop.org/)?
Title: Re: Multi Monitor Setup
Post by: Marukyu on August 01, 2014, 04:39:10 pm
It is difficult to use SFML's current fullscreen functionality with TwinView on Linux. The resolutions detected by SFML apply to the virtual screen that spans both physical screens. Switching that virtual screen's resolution often yields incorrect results:
On my system, with 1920x1080 (primary) and 1280x1024 monitors, fullscreening a 1920x1080 SFML window causes the 1280x1024 monitor to display the SFML window content stretched, and the 1920x1080 screen gets turned off entirely. Because the 1280x1024 monitor has a lower internal ID (0), it gets picked as the monitor to display the image on, even if the resolution does not match.

I am in support of adding multi monitor handling (or at least multi monitor awareness) to make SFML fullscreen work on TwinView setups without turning off the other screen or even using invalid resolutions. I've been hoping there would be some interest or progress with this issue, but I'm rather terrible at working with C code like X11's.
SDL2 handles this well (http://hg.libsdl.org/SDL/file/89e97caa2387/src/video/x11/SDL_x11modes.c), but then again, the relevant code is quite long... maybe there's room for simplification?
By the looks of it, querying/using Xinerama is sufficient to support TwinView on non-outdated Nvidia drivers.
Title: Re: Multi Monitor Setup
Post by: Gambit on December 31, 2014, 05:41:08 am
Sorry for bumping this old thread but is this still planned? I noticed the proposal is still in the issue tracker but it has been unassigned and removed from the milestones.
Title: Re: Multi Monitor Setup
Post by: Hiura on December 31, 2014, 08:38:52 am
Yes, but as you know we have a limited nan power and many many things on our TODO list so we have to prioritise things and delay others.  ;)
Title: Re: Multi Monitor Setup
Post by: Gambit on December 31, 2014, 12:00:56 pm
Recruit all of the devs!  ;D
Title: Re: Multi Monitor Setup
Post by: Pedro Bacchini on January 04, 2015, 10:16:49 am
I just start to use SFML, I have some experience in C ++ and I'm following the game development book, I have a game design that would look great in the new HP platform called Sprout using two screens, I would like to know how to contribute to SFML support for the multi-monitors.
Title: Re: Multi Monitor Setup
Post by: Ixrec on January 04, 2015, 11:25:59 am
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.
Title: Re: Multi Monitor Setup
Post by: Pedro Bacchini on January 04, 2015, 10:16:53 pm
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.
Title: Re: Multi Monitor Setup
Post by: eXpl0it3r on January 04, 2015, 10:33:14 pm
If you want to help get this implemented, here are a few things to think about and discuss:
Title: Re: Multi Monitor Setup
Post by: Pedro Bacchini on January 04, 2015, 11:29:14 pm
Excelent issues  :)

Quote
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.

Quote
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.

Quote
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.

Quote
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/
Title: Re: Multi Monitor Setup
Post by: Ixrec on January 04, 2015, 11:48:00 pm
Quote from: Pedro Bacchini on January 04, 2015, 11:29:14 pm
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.
Title: Re: Multi Monitor Setup
Post by: Gambit on January 05, 2015, 11:15:12 am
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:


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


Alternatively, the methods could be added to sf::Display where the functions would take an extra paramter which would be the window object.
Title: Re: Multi Monitor Setup
Post by: Hapax on January 05, 2015, 11:41:31 am
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).

Quote from: Ixrec on January 04, 2015, 11:48:00 pm
- 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..

Quote from: Gambit on January 05, 2015, 11:15:12 am
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 :P
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.

Quote from: Gambit on January 05, 2015, 11:15:12 am
  • 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:
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.
Title: Re: Multi Monitor Setup
Post by: Hiura on January 05, 2015, 01:21:17 pm
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)
Title: Re: Multi Monitor Setup
Post by: Gambit on January 05, 2015, 02:21:52 pm
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 :|.
Title: Re: Multi Monitor Setup
Post by: eXpl0it3r on January 05, 2015, 02:48:24 pm
Well if you have two monitors, where's the position (0, 0)? On monitor 1 or on monitor 2? ;)
Title: Re: Multi Monitor Setup
Post by: Hiura on January 05, 2015, 03:17:21 pm
And a third one for the road: How do virtual desktop play in the mix? (Do we want to support them or not? ...)
Title: Re: Multi Monitor Setup
Post by: dabbertorres on January 05, 2015, 06:22:42 pm
Quote from: eXpl0it3r on January 05, 2015, 02:48:24 pm
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).
Title: Re: Multi Monitor Setup
Post by: Hiura on January 05, 2015, 06:57:45 pm
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.
Title: Re: Multi Monitor Setup
Post by: Hapax on January 05, 2015, 07:34:40 pm
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:
(http://i.imgur.com/2whVQV6.jpg)
Title: Re: Multi Monitor Setup
Post by: Pedro Bacchini on January 06, 2015, 04:59:28 am
Quote from: dabbertorres on January 05, 2015, 06:22:42 pm
Quote from: eXpl0it3r on January 05, 2015, 02:48:24 pm
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);

Quote
sf::Display::getResolution()
perhaps to maintain compatibility get resolutions that way

static VideoMode getDesktopMode(Display display = getDisplay(0));
Title: Re: Multi Monitor Setup
Post by: Gambit on January 06, 2015, 06:46:20 am
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).
Title: Re: Multi Monitor Setup
Post by: Pedro Bacchini on January 06, 2015, 09:15:23 am
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.

Title: Re: Multi Monitor Setup
Post by: Gambit on January 06, 2015, 09:20:19 am
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?
Title: Re: Multi Monitor Setup
Post by: Pedro Bacchini on January 06, 2015, 09:41:45 am
Quote from: Gambit on January 06, 2015, 09:20:19 am
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?

Quote from: Gambit on January 06, 2015, 09:20:19 am
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.


Title: Re: Multi Monitor Setup
Post by: eXpl0it3r on January 06, 2015, 10:09:34 am
What are examples in which you need to know the display's physical location and ordering?
Title: Re: Multi Monitor Setup
Post by: Gambit on January 06, 2015, 12:28:42 pm
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.
Title: Re: Multi Monitor Setup
Post by: thomas9459 on January 06, 2015, 11:59:45 pm
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 (http://en.sfml-dev.org/forums/index.php?topic=17092.0) (which becomes even more important in multi-monitor setups), we will need to report resolution in screen coordinates and not pixels.
Title: Re: Multi Monitor Setup
Post by: Hapax on January 07, 2015, 12:40:28 am
Quote from: thomas9459 on January 06, 2015, 11:59:45 pm
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.
Title: Re: Multi Monitor Setup
Post by: Ixrec on January 07, 2015, 01:12:17 am
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 (http://msdn.microsoft.com/en-us/library/dd145136(v=vs.85).aspx):
Quote
(http://i.msdn.microsoft.com/dynimg/IC444273.png)

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.
Title: Re: Multi Monitor Setup
Post by: Gambit on January 07, 2015, 01:15:39 am
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.