[Mac] sf::VideoMode::getDesktopMode() returns wrong values for retina

[BlueCobold]

Hi.

I'm using SFML master version and have set HighResolutionCapable in my info.plist to true.
sf::VideoMode::getFullscreenModes() returns me all available modes including 2880x1800.
sf::VideoMode::getDesktopMode() however returns only 1440x900 instead of the expected 2880x1800.

Greetings

[Hiura]

It simply depends on you display settings.

[BlueCobold]

Excuse me? How can the list of *all* resolutions return me 2880x1800 while the getDesktopMode-function returns only 1440x900? That's just a bug, a missing scaling. My desktop resolution is 2880x1800 and with HighResolution-support, the function should return 2880x1800, not 1440x900. SFML also does allow me to create a window of 2880x1800 which is the size of my desktop.

[Hiura]

In Settings > Display, which resolution did you choose? Best for retina or a scaled leve?

[BlueCobold]

Best for retina.
But what does a system setting have to do with what SFML returns? If SFML reports the highest possible resolution to be 2880x1800, why would it report the desktop to have a lower resolution than that while the user currently *is* using the highest possible desktop resolution? That sounds very implausible.

[Hiura]

Best for retina is not full 2880x1800... Change the settings to the different level of scale and run

#include <SFML/Graphics.hpp>

#include <iostream>

std::ostream& operator<<(std::ostream& out, sf::VideoMode vm) {
    return out << "{" << vm.width << ", " << vm.height << "}";
}

int main(int, char const**)
{
    std::cout << "Desktop: " << sf::VideoMode::getDesktopMode() << std::endl;
    return 0;
}
 

and see what happens. You'll see that SFML reflect the user's settings pretty well.

[Laurent]

Isn't there a confusion between physical and logical pixels here?

[BlueCobold]

Yea, if I change the scale, it changes in SFML too. But thats still not logical. I expect SFML to return me all physical resolutions - ie the number of actual pixels I can address separately. That includes the desktop resolution. And that one isn't changing at all.
In other words:
sf::VideoMode::getFullscreenModes() returns physical pixel resolutions - independent of screen scaling
sf::VideoMode::getDesktopMode() returns logical point resolution - dependent on screen scaling
This is inconsistent. As a developer, requesting the desktop resolution and creating a window of that size should result in a window having the desktop size. But that isn't happening

[eXpl0it3r]

As thomas9459 has said before SFML needs to do more to fully support high DPI screens. As such this feature request thread might be of importance here as well and it seems like BlueCobold already found the other related thread.

[BlueCobold]

Yea, but what's the consent now? This issue won't be touched until SFML will have high DPI support in general? Because if so, I will have to make a temporary fix on that myself.

[Hiura]

We definitely need improvement regarding the monitor capabilities/API, but here it's a bug: the size returned by sf::VideoMode::getDesktopMode() don't take the scaling factor into account but sf::Window::create does. Sorry for the earlier misleading answers.

The behaviour should be consistent when `High Resolution Capable` is set to `NO` in the app's plist file.

[BlueCobold]

Yes, it is OK for non-retina devices or when having HighResolutionCapable set to NO. When setting it to YES on retina devices, the problem occurs.