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

Author Topic: Windows OS ::getDesktopMode() fix  (Read 17862 times)

0 Members and 1 Guest are viewing this topic.

Hydra

  • Newbie
  • *
  • Posts: 37
    • View Profile
Windows OS ::getDesktopMode() fix
« on: August 17, 2015, 08:00:19 pm »
I was looking through the documentation on ways to make a window the size of the screen. I found this page:

http://www.sfml-dev.org/tutorials/2.3/window-window.php

If you look at the bottom it says (in exact words):

For some reason, Windows doesn't like windows that are bigger than the desktop. This includes windows created with VideoMode::getDesktopMode(): with the window decorations (borders and titlebar) added, you end up with a window which is slightly bigger than the desktop.

I was almost certain there was a way to fix this and make it work for Windows. I'm using Windows 10 operating system, 64 bit version. I tested and it does indeed produce errors. It gets the correct size but places the window 9 pixels to the right. I managed to fix it with:

window.setPosition(-9, 0)

This was perfectly fine but I wanted to find out why it was 9 pixels difference. I managed to find out that that is the size of the frame surrounding the window. I created a C++ project in CodeBlocks not using SFML. Because according to the documentation this only happens in Windows OS's I was able to narrow it down to fixes that only involved Windows OS's. Thus, I could use the default <window.h> class in C++ for Windows. I produced this code which gets the window's surrounding frame size:

#include <windows.h>

#include <iostream>

int main()
{
    std::cout << GetSystemMetrics(SM_CXSIZEFRAME) << std::endl;
}

That code produces the size frame's width. Which produced 9, confirming that it is the frame causing windows to be rendered 9 pixels to the right. In Window's you can change the frame size so you can't really just say minus 9 pixels as it can be changed. Thus I began work on a more dynamic solution. Here is my code which renders the window correctly:

#include <SFML/Graphics.hpp>

#include <windows.h>

int main()
{
    sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "Majestic SFML Window");

    window.setPosition(sf::Vector2i(0 - GetSystemMetrics(SM_CXSIZEFRAME), 0));

    while (window.isOpen())
    {
        sf::Event event;

        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
            {
                window.close();
            }
        }

        window.clear(sf::Color::Black);

        window.display();
    }

    return 0;
}
 


I am fairly certain that the developer of SFML (I think he's called Laurent) can edit SFML to include this. Obviously you cannot just do this as this wouldn't work on other OS's like Mac and Linux. But that's as simple as checking whether the operating system is Window's and if so then run another class to subtract the size frame's size.

So yeah, basically I was wondering if you could fix this bug.[/code]
« Last Edit: August 17, 2015, 09:05:09 pm by Hydra »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Re: Windows OS ::getDesktopMode() fix
« Reply #1 on: August 17, 2015, 08:17:38 pm »
You misunderstood the statement there. The statement was about Windows sometimes not acting correctly with windows that are bigger than the display resolution, e.g. Windows might just not display the window at all. That the this also applies to the windows that have the same size as the display resolution since decorations are added, is just a remark. As the text already says "with the window decorations (borders and titlebar)" we are aware the the frame and titlebar are added, but it's not a "bug". If someone wants to have a window that has the same resolution as the display but still have window decorations they'll have to deal with the offset themselves. ;)

Also you should make use of the [code=cpp][/code] tags.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Hydra

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #2 on: August 17, 2015, 08:24:44 pm »
You misunderstood the statement there. The statement was about Windows sometimes not acting correctly with windows that are bigger than the display resolution, e.g. Windows might just not display the window at all. That the this also applies to the windows that have the same size as the display resolution since decorations are added, is just a remark. As the text already says "with the window decorations (borders and titlebar)" we are aware the the frame and titlebar are added, but it's not a "bug". If someone wants to have a window that has the same resolution as the display but still have window decorations they'll have to deal with the offset themselves. ;)

Also you should make use of the [code=cpp][/code] tags.

How is having a user write:

setPosition(0, 0)

Which then acts like:

setPosition(9, 0)

Not a bug? It seems very strange to leave something like that in SFML. It just completely confuse's beginners as how are they suppose to know that the window is going to be 9 pixels to the right. Wouldn't it just be simpler to fix it so that users don't report it as a bug or ask for help.
« Last Edit: August 17, 2015, 08:28:26 pm by Hydra »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Re: Windows OS ::getDesktopMode() fix
« Reply #3 on: August 17, 2015, 08:35:00 pm »
It's not SFML's "fault". We call the WinAPI to place the window at 0, 0 and Windows moves it in by the width of the window decoration. It's "normal" behavior on Windows and if we did add such a change, it would be a hack and not bug fix because we actively work around Windows' behavior.
As such the behavior gets documented so the users can understand what's going on and if they really have an issue with it they can, as you've shown, "fix" it themselves.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Hydra

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #4 on: August 17, 2015, 08:40:54 pm »
It's not SFML's "fault". We call the WinAPI to place the window at 0, 0 and Windows moves it in by the width of the window decoration. It's "normal" behavior on Windows and if we did add such a change, it would be a hack and not bug fix because we actively work around Windows' behavior.
As such the behavior gets documented so the users can understand what's going on and if they really have an issue with it they can, as you've shown, "fix" it themselves.

Yes, it may be a hack around what Windows OS's want to do but it still makes SFML work as I believe should be intended. Consider for example a beginner SFML code writer. She/he begins writing basic SFML code and following online tutorials. She/he searches for making a full windowed window. She/he then types in that code. She/he that doesn't understand why her/his window is not lining up properly. She/he either goes to the forums for help, stops using it, or searches online for fixes.

There's absolutely no reason why SFML includes what I consider a bug. If a function does not work as intended then it is not working correctly and is a bug. Unless the developers intended setPosition(0, 0) to move your window 9 pixels to the right. This could easily be fixed and avoid all confusion.

From what I know SDL does not feature this and it works as users intend it to. Also, I'd like to add that are you trying to say that every time I want to fix this behavior on a project I'm working on I have to waste time fixing something that SFML does wrong?
« Last Edit: August 17, 2015, 08:43:06 pm by Hydra »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Windows OS ::getDesktopMode() fix
« Reply #5 on: August 17, 2015, 08:57:20 pm »
I just tested it and the window, with decorations and desktop size, is correctly placed at (0, 0). If there's some empty space (9 pixels) for you then this is actually a real bug, and a proper & complete report would be welcome ;)
Laurent Gomila - SFML developer

Hydra

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #6 on: August 17, 2015, 09:02:46 pm »
I just tested it and the window, with decorations and desktop size, is correctly placed at (0, 0). If there's some empty space (9 pixels) for you then this is actually a real bug, and a proper & complete report would be welcome ;)

I'd just like to make sure. You are using Windows right?

I believe I may of misread the documentation saying there's a problem with oversizing but then I've discovered something different? Using just this code:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "Majestic SFML Window");

    while (window.isOpen())
    {
        sf::Event event;

        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
            {
                window.close();
            }
        }

        window.clear(sf::Color::Black);

        window.display();
    }

    return 0;
}
 

On a Windows 10, 64 bit computer produces this:


Hydra

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #7 on: August 17, 2015, 09:04:17 pm »
The window is offset from the left by 9 pixels. It's the correct size though. The offset I've discovered is simply the window frame which is fixed by using the code I said at the top.

Hapax

  • Hero Member
  • *****
  • Posts: 3346
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Windows OS ::getDesktopMode() fix
« Reply #8 on: August 18, 2015, 12:13:29 am »
I also just tried this and it's fine here too (Windows 7).
Two things:
  • Have you a setting that removes window frames in the OS? There doesn't seem to be any frame in your screenshot.
  • Have you tried the window with sf::Style::None?
You may want to make sure that you can close the window via a keypress or something if you make a desktop-sized window with no decorations.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Windows OS ::getDesktopMode() fix
« Reply #9 on: August 18, 2015, 08:03:16 am »
The fact that your decorations are plain black, like the background, makes it difficult to figure out what happens... Maybe you could clear the window with white or any other color than black.

And yes, I tested on Windows 8.1.

Quote
I believe I may of misread the documentation saying there's a problem with oversizing
There is indeed a problem in this case, but as far as I know, not this one.

By the way, what happens if you use desktop mode minus 9 pixels (ie the window fits entirely on screen)?
Laurent Gomila - SFML developer

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #10 on: August 18, 2015, 01:02:52 pm »
Are you using any custom styling program? By default, all Windows 10 title bars should be full white with a colored outline around the whole window. Your program clearly doesn't show that.

Edit:
Just for reference, this is what a standard Windows 10 window is supposed to look like:

« Last Edit: August 18, 2015, 01:09:02 pm by Mario »

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: Windows OS ::getDesktopMode() fix
« Reply #11 on: August 18, 2015, 01:07:03 pm »
This looks like it may be similar issue as the one described in this thread. Any chance you are running a duel GPU setup?

http://en.sfml-dev.org/forums/index.php?topic=18784
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #12 on: August 18, 2015, 01:10:39 pm »
Quick update: I can reproduce the issue... Hum! I'm surprised. :)

So Hapax is obviously indeed toying around with window colors, but that's no skinning problem - it's something else.

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #13 on: August 18, 2015, 01:44:23 pm »
Creating another reply in case someone subscribed to the thread. :)

It's not a bug, it's a feature! (kinda...)

While this might be a bug in the window manager I assume this is a tiny oversight regarding usability, especially considering touch users.

While the window borders shrunk to 1 pixel thickness in Windows 10, Microsoft kept the old "thick borders"  behind the scenes for easier resizing.

Here you can see it in action:



As you can see, from the top, the cursor changes as the cursor touches the actual window.

But from the left, the cursor changes quite a bit earlier. This invisible part of the border is what causes that "gap" when displaying the windowed full screen with borders.

Unfortunately, that part is there, no matter what you do, unless you're rendering no border at all.

Possible workaround (Feedback needed!):

By default, SFML windows are centered on screen, unless the Window is bigger than the screen (then it's pinned on the top left corner). This causes the gap observed by the OP.

We could compare a window's dimensions with the desktop resolution. If the window would become bigger, we'd manually place it centered, essentially skipping this part. What do you think?
« Last Edit: August 18, 2015, 01:46:53 pm by Mario »

Hydra

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Windows OS ::getDesktopMode() fix
« Reply #14 on: August 18, 2015, 01:49:50 pm »
Are you using any custom styling program? By default, all Windows 10 title bars should be full white with a colored outline around the whole window. Your program clearly doesn't show that.

Edit:
Just for reference, this is what a standard Windows 10 window is supposed to look like:



Ah, that may be it actually. I'm using a theme for windows. Though as far as I'm concerned themes only change the colors and icons. They don't change the dimensions of anything.