SFML RenderWindow taking a long time to open a window

Viewed 834

I know this is essentially a duplicate, but this wasn't ever answered. I'd like to mention that I have followed the tutorial for using SFML along with Visual Studio, and I'm running a 64-bit project with 64-bit SFML. The window loaded instantly a few times, and now consistently takes 40 seconds to open on new builds/debugs. I also have the downloading of debug symbols off. My graphics drivers are up to date and my HDD is fine. This is the code:

 #include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");//This one
sf::CircleShape shape(100.f);
shape.setFillColor(sf::Color::Green);

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

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

return 0;
}

Everything runs at normal speed, except for RenderWindow, which again, takes exactly 40 seconds every time. Does anyone know how I could fix this? I've been having this issue for a few weeks now.

e: Could it be my CPU? It's not the best but I can still run most games just fine as I have a 1050ti. My current CPU is an i5-2500k, although I believe I got the same issue on an A10-5800k.

3 Answers

EDIT: Before you resort to the solution below, try updating your keyboards firmware! You're most likely using a Corsair keyboard, so download Corsair's iCue and update your keyboard drivers. This will most likely fix these issues. If it didn't work, then try the following:

Since OP didn't reply any further, I tried to find a workaround myself, as this issue still exists in 2020. This workaround requires you to compile the libraries yourself. So download the source code and change the following:

  • In WindowImpl.cpp, navigate to the function WindowImp::WindowImp and comment out the whole function body.
  • In WindowImpl.cpp, navigate to WindowImp::popEvent and comment out the call to processJoystickEvents

As long as you don't use the Joystick part of SFML this should work without issues.

An contributor on the SFML discord helped me source the issue by going through and showing me how to look through the callstack, and it turned out that the freeze was when polling for dx input, and after a little bit of experimenting we figured out my k55 keyboard was to blame. I'll try to find a fix later tonight, but in short term situations unplugging it makes everything work fine.

I have the same keyboard (Corsair K55). The problem for me was Corsair's iCue software, and quitting it entirely fixed the problem for me without having to unplug my keyboard.

Related