Multi Monitor Setup

[Foaly]

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.

[Strelok]

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.

[Foaly]

Well... that's exactly my point
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)
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.

[Hapax]

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

[Ixrec]

The problem here is that you've now posted code that proves that SFML might not needed to be altered

It's Windows-specific code, so it doesn't prove that at all.

[Hapax]

I think "prove" was used a bit strongly, sorry. I did mean, however, that it 'suggests' ( ) 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 

[Foaly]

Haha good! Then we are on the same page 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.

[eXpl0it3r]

I'm not sure about the details, but there are two points one should keep in mind:

• SFML currently isn't even aware that there are multiple monitors. Thus even if we wanted to implement your "simple" proposal one needs to refactor many internal parts.
• Monitors might be coupled with different graphic cards. So when you retrieve context or shader information from your "primary" monitor and the use it on your "secondary" gpu there might occurr some issues.

Maybe I make it sound worse than it actually is, but as I said, I don't know the details. ;)

[Foaly]

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

[Jesper Juhl]

Also keep Xinerama in mind...
And in the future, how will this work with Wayland?

[Marukyu]

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

[Gambit]

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.

[Hiura]

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. 

[Gambit]

Recruit all of the devs! 

[Pedro Bacchini]

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.