Skip to content
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

Fullscreen leaves zombie window open on macOS #1581

Closed
JonnyPtn opened this issue Apr 29, 2019 · 3 comments · Fixed by #1814
Closed

Fullscreen leaves zombie window open on macOS #1581

JonnyPtn opened this issue Apr 29, 2019 · 3 comments · Fixed by #1814

Comments

@JonnyPtn
Copy link
Contributor

JonnyPtn commented Apr 29, 2019

Subject of the issue

on macOS if you make a window fullscreen then go back to windowed, there will be a zombie window left open with nothing rendered to it

Your environment

  • macOS Mojave
  • Latest master (have reproduced as far back as 2.3)
  • Xcode 10.2

Steps to reproduce

Simply make the window fullscreen then windowed again

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1280, 720), "Minimal, complete and verifiable example");
    window.setFramerateLimit(60);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            if (event.type == sf::Event::KeyPressed)
            {
                static bool fullscreen = true;
                window.create(sf::VideoMode(1280,720), "Non-zombie window", fullscreen ? sf::Style::Fullscreen : sf::Style::Default);
                fullscreen = !fullscreen;
            }
        }

        window.clear();
        window.display();
    }
}

Expected behavior

There should only ever be one window

Actual behavior

After returning from fullscreen to windowed, there is a zombie window left behind

Notes

The zombie window seems to have the size/title of the window before going fullscreen (i.e. in the example code above it will have the original title from when it was created, not the new one)

This doesn't seem to be cumulative, i.e. if I continue to toggle full screen it won't create further windows

I tested just recreating the window without going fullscreen, and there is no issue, so it is somehow related to going fullscreen

@chusloj
Copy link

chusloj commented Feb 3, 2021

@JonnyPtn Looking through old posts to SFML forums voicing the same concerns as you, sf::Style::Fullscreen doesn't seem to be the way to directly change a window to fullscreen based on OSX's definition of fullscreen anymore (changing to a different window separate from the desktop). Now, the best approximation is to use sf::VideoMode::getFullscreenModes(). I haven't looked into this issue too extensively, but from what I know this is because of how OSX is set up and how interfacing with OS capabilities such as fullscreen is much easier with DirectX on Windows.

As for your code, a simple work-around would be to use sf::VideoMode::getFulscreenModes() to use the most appropriate video mode provided by that function:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1280, 720), "Minimal, complete and verifiable example");
    window.setFramerateLimit(60);
    
    static bool fullscreen = true;

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            if (event.type == sf::Event::KeyPressed)
            {
                window.create(fullscreen ? sf::VideoMode::getFullscreenModes()[0] : sf::VideoMode(1280, 720), "Non-zombie window");
                fullscreen = !fullscreen;
            }
        }

        window.clear();
        window.display();
    }
}

Also:

Your Environment

OSX Big Sur
SFML 2.5

When running your code, I receive the following message:

The requested video mode is not available, switching to a valid mode

@eXpl0it3r
Copy link
Member

eXpl0it3r commented Aug 9, 2021

@JonnyPtn / @chusloj could you give #1814 a try?
I'm unable to reproduce the mentioned issue on Big Sur

@eXpl0it3r eXpl0it3r added this to the 2.6 milestone Aug 9, 2021
@eXpl0it3r eXpl0it3r added this to Discussion in SFML 2.6.0 via automation Aug 9, 2021
@eXpl0it3r eXpl0it3r moved this from Discussion to Review & Testing in SFML 2.6.0 Aug 9, 2021
SFML 2.6.0 automation moved this from Review & Testing to Done Aug 12, 2021
@eXpl0it3r
Copy link
Member

If this wasn't fixed by the mentioned PR, feel free to reopen the issue. As said, I can't reproduce it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
SFML 2.6.0
  
Done
Development

Successfully merging a pull request may close this issue.

3 participants