Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Multi monitor support  (Read 26434 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Multi monitor support
« Reply #45 on: October 02, 2015, 03:15:46 pm »
And when you think about it screen changes are unlikely to happen while the program runs. Usually you set your screens up, before you start a program.
It doesn't matter as long as they do happen. The library shouldn't just break down because we didn't consider this case.

So if a screen change event occurs you could simply set a flag and recompute the internal screen data at the next use.
How do you detect a change in configuration? How do you signal it to the user?

I think the data should be cached internally. It makes screens a lighter resource. [...] These are ideal conditions for caching. If you only hand out copys or references you also don't have problems with invalid pointers.
Yes, but either you return a copy of the whole vector (which is expensive and partially negates the caching advantage), or you return a reference (which brings back the problem of changing configuration during usage).

I'd personally weigh the performance argument less important than the validity one, so I tend to return a copy.

To keep a getByIndex() function would be helpful I think. I can think of cases where users want to get a screen from it's index (for example get the screen corresponding to a video mode), instead of copying the whole vector and the only pick one element.
I don't think this is necessary. If the user is really concerned about performance, he can store the vector himself.

Another reason why I wouldn't provide an index-based function is that it brings back the danger of outdated information: it's possible that the index which the user memorized refers to a meanwhile different screen.

There are two other things I'd like to discuss. First is I'd like to suggest a sf::Screen::contains(sf::Vector2) function. I can think of use cases where the user wants a window to go fullscreen on the monitor it's currently on. Right now there is no way to do it.
What about screen.bounds.contains(vector)? What if the user wants the working area instead of bounds? It's too specific in my opinion.

In general, I don't like introducing specific functionality just for convenience reasons. As always in designing a new API, we should start with the minimal set of functionality, and extend it later based on user's needs. It's difficult to anticipate everything, and deprecating APIs because of wrong assumptions is much worse than introducing them a bit later.



There are really many parallels to the sf::Joystick API. How do we handle joystick changes at runtime meaningfully? The more I think about it, the more it seems that we've made some design mistakes there. We should definitely reconsider this whole topic for SFML 3, also to unify the differently looking APIs.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Multi monitor support
« Reply #46 on: October 02, 2015, 05:52:20 pm »
And when you think about it screen changes are unlikely to happen while the program runs. Usually you set your screens up, before you start a program.

This assumption will, I believe, be incorrekt sooner than you think. On OS X you can already play with the DPI to have more or less "space" on your screen. But that's not why I think it will change: with the recent shift in device usage, more and more tablets are being used and solution to plug in a screen to your tablet are coming rapidly to have a better nomad usage of our computers (think of AirPlay, Microsoft Surface docking stations and whatnot).

There are really many parallels to the sf::Joystick API. How do we handle joystick changes at runtime meaningfully? The more I think about it, the more it seems that we've made some design mistakes there. We should definitely reconsider this whole topic for SFML 3, also to unify the differently looking APIs.
Yes, definitely.

How do you detect a change in configuration? How do you signal it to the user?

Currently we only have events accessible through windows. So there's basically two solutions I can think of: a) continue to use this system, send a screen configuration change to all opened windows and document that sf::Screen's data should be used with as little delay as possible to create a window (*), or b) add a static sf::System::pollEvent for non-window specific events.

As I said before, I think in a first time we can just omit those configuration change event and focus on how the Screen's data is used/accessed.

(*) if it's done at the application start, it's unlikely to be an issue since no decent user should launch an app and at the same time plug a display.
SFML / OS X developer