New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DPI Scaling causing strange results on normal settings #679

Open
majesty2450 opened this Issue Aug 17, 2014 · 11 comments

Comments

Projects
None yet
4 participants
@majesty2450

majesty2450 commented Aug 17, 2014

There appears to be a bug with DPI scaling. I'm using a windows 8.1, surface pro 2, 256gb.

On normal .exe settings the window "appears" larger than it should and under fullscreen mode graphics "appear" almost like they have been zoomed into, like the view has been scaled.

Here is a link to the original forum post: http://en.sfml-dev.org/forums/index.php?topic=15176.0

Here is a link to were I have source to a demo application where running it using the specs I am using will reproduce what I am talking about: https://gist.github.com/majesty2450/ba1e806efe6b540f99e2. At the top of the source there is instructions on how to better see the problem.

Here are some screenshots that show what I am talking about using the demo I linked to above:
screenshot 62
screenshot 63
screenshot 64
screenshot 65

@eXpl0it3r eXpl0it3r added bug labels Aug 17, 2014

@eXpl0it3r eXpl0it3r added this to the 2.x milestone Aug 17, 2014

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Aug 17, 2014

Member

Try including windows.h and adding this code block in your main() before creating the window:

HINSTANCE user32Dll = LoadLibrary("user32.dll");

if (user32Dll)
{
    typedef BOOL WINAPI (*SetProcessDPIAwareFuncType)(void);
    SetProcessDPIAwareFuncType SetProcessDPIAwareFunc = GetProcAddress(user32Dll, "SetProcessDPIAware");

    if (SetProcessDPIAwareFunc)
    {
        std::cout << "SetProcessDPIAware() available on this system, calling now.\n";

        if (SetProcessDPIAwareFunc())
        {
            std::cout << "SetProcessDPIAware() call succeeded.\n";
        }
        else
        {
            std::cout << "SetProcessDPIAware() call failed.\n";
        }
    }
    else
    {
        std::cout << "SetProcessDPIAware() unavailable on this system.\n";
    }

    FreeLibrary(user32Dll);
    user32Dll = NULL;
}
else
{
    std::cout << "Could not open user32.dll.\n";
}

And see if that fixes the issue.

The combined gist can be found here: https://gist.github.com/binary1248/175b7fd50c0fc8738c06

Member

binary1248 commented Aug 17, 2014

Try including windows.h and adding this code block in your main() before creating the window:

HINSTANCE user32Dll = LoadLibrary("user32.dll");

if (user32Dll)
{
    typedef BOOL WINAPI (*SetProcessDPIAwareFuncType)(void);
    SetProcessDPIAwareFuncType SetProcessDPIAwareFunc = GetProcAddress(user32Dll, "SetProcessDPIAware");

    if (SetProcessDPIAwareFunc)
    {
        std::cout << "SetProcessDPIAware() available on this system, calling now.\n";

        if (SetProcessDPIAwareFunc())
        {
            std::cout << "SetProcessDPIAware() call succeeded.\n";
        }
        else
        {
            std::cout << "SetProcessDPIAware() call failed.\n";
        }
    }
    else
    {
        std::cout << "SetProcessDPIAware() unavailable on this system.\n";
    }

    FreeLibrary(user32Dll);
    user32Dll = NULL;
}
else
{
    std::cout << "Could not open user32.dll.\n";
}

And see if that fixes the issue.

The combined gist can be found here: https://gist.github.com/binary1248/175b7fd50c0fc8738c06

@majesty2450

This comment has been minimized.

Show comment
Hide comment
@majesty2450

majesty2450 Aug 17, 2014

The code you provided did not compile at first, after a little playing with it I was able to get it to compile the way I did this was by changing this line: typedef BOOL WINAPI (*SetProcessDPIAwareFuncType)(void); to this line: typedef BOOL(WINAPI *SetProcessDPIAwareFuncType)(void);.

The version that compiled for me can be found here: https://gist.github.com/majesty2450/a2e74d2a8da9b845bdb4

Once I ran the program and tested it, SetProcessDPIAware() was successfully called. The problem also appeared fixed as shown with these screenshots:
screenshot 66
screenshot 67
screenshot 68
screenshot 69

I also tried adding the solution to previous code where I first discovered this and it appears to fix the problem there as well. Thank you.

majesty2450 commented Aug 17, 2014

The code you provided did not compile at first, after a little playing with it I was able to get it to compile the way I did this was by changing this line: typedef BOOL WINAPI (*SetProcessDPIAwareFuncType)(void); to this line: typedef BOOL(WINAPI *SetProcessDPIAwareFuncType)(void);.

The version that compiled for me can be found here: https://gist.github.com/majesty2450/a2e74d2a8da9b845bdb4

Once I ran the program and tested it, SetProcessDPIAware() was successfully called. The problem also appeared fixed as shown with these screenshots:
screenshot 66
screenshot 67
screenshot 68
screenshot 69

I also tried adding the solution to previous code where I first discovered this and it appears to fix the problem there as well. Thank you.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Aug 18, 2014

Member

Fixed in 3493352.

Member

binary1248 commented Aug 18, 2014

Fixed in 3493352.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Aug 18, 2014

Member

@majesty2450 would be great if you could test the actual PR as well.

Also if anyone else with a high DPI display could test this, we'd really appreciate it.

The PR has been added to my merge list. If the tests and reviews don't raise any concerns it will be merged soon.

Member

eXpl0it3r commented Aug 18, 2014

@majesty2450 would be great if you could test the actual PR as well.

Also if anyone else with a high DPI display could test this, we'd really appreciate it.

The PR has been added to my merge list. If the tests and reviews don't raise any concerns it will be merged soon.

@majesty2450

This comment has been minimized.

Show comment
Hide comment
@majesty2450

majesty2450 Aug 18, 2014

I'd be happy too, however a few questions:

  1. I have relatively little experience with github and therefore may have trouble with actually getting the code to test it... :( I was able to clone it by pressing button that has the tooltip "Check this branch in GitHub for Windows" within the "This project can be automatically merged by project collaborators." area and then I manually built it using cmake and my compiler. Is that right?
  2. How would you like me to test it? Anything special or same thing I did above / one of my projects?

majesty2450 commented Aug 18, 2014

I'd be happy too, however a few questions:

  1. I have relatively little experience with github and therefore may have trouble with actually getting the code to test it... :( I was able to clone it by pressing button that has the tooltip "Check this branch in GitHub for Windows" within the "This project can be automatically merged by project collaborators." area and then I manually built it using cmake and my compiler. Is that right?
  2. How would you like me to test it? Anything special or same thing I did above / one of my projects?
@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Aug 19, 2014

Member

For 1) you can either download the branch as ZIP archive or clone it with git and then checkout the branch as following:

git clone https://github.com/LaurentGomila/SFML.git
git checkout bugfix/windows_dpi_scaling

As for 2) same as before, just run it and see if it fixes that issue.

Member

eXpl0it3r commented Aug 19, 2014

For 1) you can either download the branch as ZIP archive or clone it with git and then checkout the branch as following:

git clone https://github.com/LaurentGomila/SFML.git
git checkout bugfix/windows_dpi_scaling

As for 2) same as before, just run it and see if it fixes that issue.

@majesty2450

This comment has been minimized.

Show comment
Hide comment
@majesty2450

majesty2450 commented Aug 19, 2014

ok thanks

@eXpl0it3r eXpl0it3r modified the milestones: 2.x, 2.2 Aug 19, 2014

jcowgill added a commit to jcowgill/SFML that referenced this issue Sep 22, 2014

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Dec 25, 2016

Member

Seems like a non-standard DPI is still broken or at least not working as expected under Windows 10 (can't test other systems).

When creating a 1024x768 fullscreen window on my Surface Pro (running at 200% scaling by default), the display will switch to the correct resolution, but the actual SFML window will only fill the top left portion of the screen.

Running the same window in windowed mode will not scale the window, so it also appears smaller.

Member

MarioLiebisch commented Dec 25, 2016

Seems like a non-standard DPI is still broken or at least not working as expected under Windows 10 (can't test other systems).

When creating a 1024x768 fullscreen window on my Surface Pro (running at 200% scaling by default), the display will switch to the correct resolution, but the actual SFML window will only fill the top left portion of the screen.

Running the same window in windowed mode will not scale the window, so it also appears smaller.

@MarioLiebisch MarioLiebisch reopened this Dec 25, 2016

@MarioLiebisch MarioLiebisch modified the milestones: 2.4.2, 2.2 Dec 25, 2016

@MarioLiebisch MarioLiebisch self-assigned this Dec 25, 2016

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Dec 25, 2016

Member

Forgot to mention, I've identified the issue for fullscreen windows (there's no problem with non-fullscreen windows). Working on a patch soon™.

Member

MarioLiebisch commented Dec 25, 2016

Forgot to mention, I've identified the issue for fullscreen windows (there's no problem with non-fullscreen windows). Working on a patch soon™.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Jan 18, 2017

Member

How soon is soon, @MarioLiebisch?

Member

eXpl0it3r commented Jan 18, 2017

How soon is soon, @MarioLiebisch?

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Jan 18, 2017

Member

Work stuff caught me off-guard. Main problem: it's more complicated than it should be, mostly due to the fact that SFML uses the same values for both window sizes as well as resolutions, where some have to be scaled and others don't (i.e. they'd have to diverge here). For example, a 1280x1024 windowed window right now has a different size than a 1280x1024 fullscreen window and you can't just apply the sizes/resolutions you get reported. To make it even more interesting, changed DPI scaling isn't necessarily applied immediately, not even when your app is set to "per monitor aware". Add in support for Vista and older and you've got something interesting to do lots of trial and error on.

To get back to the example above, when creating a 1024x768 fullscreen window, screen resolution will switch to 2048x1536 or so to ensure the 200% DPI scaling. This leads to the window only covering 1/4th of the space it should. We might be able to get away by just downscaling the fullscreen resolution according to the calculated DPI, but this needs more testing.

Member

MarioLiebisch commented Jan 18, 2017

Work stuff caught me off-guard. Main problem: it's more complicated than it should be, mostly due to the fact that SFML uses the same values for both window sizes as well as resolutions, where some have to be scaled and others don't (i.e. they'd have to diverge here). For example, a 1280x1024 windowed window right now has a different size than a 1280x1024 fullscreen window and you can't just apply the sizes/resolutions you get reported. To make it even more interesting, changed DPI scaling isn't necessarily applied immediately, not even when your app is set to "per monitor aware". Add in support for Vista and older and you've got something interesting to do lots of trial and error on.

To get back to the example above, when creating a 1024x768 fullscreen window, screen resolution will switch to 2048x1536 or so to ensure the 200% DPI scaling. This leads to the window only covering 1/4th of the space it should. We might be able to get away by just downscaling the fullscreen resolution according to the calculated DPI, but this needs more testing.

@eXpl0it3r eXpl0it3r modified the milestones: 2.5, 2.4.2 Jan 31, 2017

@eXpl0it3r eXpl0it3r added this to Discussion in SFML 2.5.0 Feb 2, 2017

@binary1248 binary1248 removed their assignment Mar 4, 2017

@eXpl0it3r eXpl0it3r removed this from the 2.5 milestone Jan 25, 2018

@eXpl0it3r eXpl0it3r removed this from Discussion in SFML 2.5.0 Jan 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment