SFML community forums
Help => General => Topic started by: anthnich on January 28, 2016, 08:07:07 pm
-
Just want to report an issue. I'm using the latest SFML.
I'm experiencing a similar thing this user ran into (since fixed for him):
http://en.sfml-dev.org/forums/index.php?topic=18803.0
I originally had this problem in Ubuntu but it was solved some time ago as you can see with the same patch:
http://en.sfml-dev.org/forums/index.php?topic=18799
A player of my game is having this problem on the Solus Linux OS. https://solus-project.com/
I was able to replicate it. When my game is launched, within 5 seconds I get the "Force Quit/Wait" dialog. Clicking "Wait" allows the game to played w/o problems and everything else seems to work fine. The "Force/Quit" will also popup intermittently for another user. I just experience on first launch.
I feel that this is possibly related to the original issue. No other Linux distro I tested (Ubuntu, Debian, ArchLinux) seems to have this problem. Thought I'd let you know.
-
As far as I can see, Solus Linux uses Gnome_Desktip.
I rember having a problem like that with Gnome-Desktop under Debian while loading.
Been some time, so it might not be helpful to your problem.
I think the problem was, that loading all my assests took a few seconds, so Gnome though my application was not responding.
I fixed that issue by calling PollEvent() before I loaded the assests so Gnome saw my application was responding.
-
The game is actually running fine when it happens.
Thanks for the suggestion, but I tried pollevents on startup and it didn't fix it.
-
AFAIK the problem lies with Mutter (Gnome's window manager).
If an application doesn't respond (for SFML this should be PollEvent()), Mutter shows your message.
So if you poll your events on startup, then load all your assests it might be already too long for Mutter.
-
Couldn't you just do a
while (pollEvent());
inbetween loading each individual asset so it gets called regularly and gets to empty the event queue regularly (and then of course once per frame as the game is running).
-
I poll the event queue regularly, so it is not that.
That's what is strange. PollEvent is being run AS I get the "Force Quit" dialog. PollEvent, up to that point, had been running regularly leading up to the freeze.
My game takes maybe a second to first load. So the window manager sees it as a freeze that quickly?
-
Same issue, but Fedora 23 with Gnome3 Desktop.
Windowed apps don't trigger the 5 second warning, fullscreen apps do.
(http://s32.postimg.org/8dpydevit/Screenshot.png)
SFML-2.3.2-1.fc23.x86_64
Linux 4.4.8-300.fc23.x86_64 #1 SMP GNU/Linux
Fedora release 23 (Twenty Three)
What other information do you need?
-
And what code did you run?
-
Exploiter, thank you for your rapid reply. The code I used is below:
#include <SFML/System.hpp>
#include <SFML/Graphics.hpp>
int main()
{
// Create the main window
sf::RenderWindow app(sf::VideoMode(1920, 1080), "SFML window", sf::Style::Fullscreen);
//sf::RenderWindow app(sf::VideoMode(1920, 1080), "SFML window");
//app.setFramerateLimit(30);
// Load a sprite to display
sf::Texture texture;
if (!texture.loadFromFile("../../../assets/images/star.png")) return EXIT_FAILURE;
sf::Sprite sprite(texture);
sprite.setOrigin(sprite.getGlobalBounds().width / 2, sprite.getGlobalBounds().height / 2);
// Start the game loop
while (app.isOpen())
{
//sf::sleep(sf::milliseconds(100));
// Process events
sf::Event event;
while (app.pollEvent(event))
{
// Close window : exit
if (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape) app.close();
if (event.type == sf::Event::Closed) app.close();
}
// Clear screen
app.clear();
// Draw the sprite
sprite.setPosition(sf::Mouse::getPosition(app).x, sf::Mouse::getPosition(app).y);
app.draw(sprite);
// Update the window
app.display();
}
return EXIT_SUCCESS;
}
As you may see I tried sleep, framerates and a some odd solutions that had no ultimate effect.
Edit: As you can tell by my use of getGlobalBounds where I should have used getLocalBounds -- I'm comming back to tinker from a long break.
Edit2: Inserting sf::sleep(sf::seconds(0)); after app.display(); seems to prevent the supposed hang about half the time. It could be a clue!
-
I have the same problem with my game under Fedora 23 (Gnome 3.20).
-
Sounds like Gnome expects some other Xlib call that SFML isn't sending. Time to summon binary1248. :P
-
I'm not familiar with binary1248, but if I can help to further resolve this issue in any fashion, I'm happy to help. I'll keep an eye on this thread. And thank you again Exploiter.
-
Just tested the same code on:
Fedora 23
SFML-2.3.2-1.fc23.x86_64
Linux 4.4.8-300.fc23.x86_64
gnome-shell 3.18.5-1.fc23.x86_64
could not reproduce...
victorlevasseur, I'm interested, how did you manage to get 3.20 on Fedora 23? If it happens to be through some unofficial means, then it is possible that there might be some compatibility issues involved that are not related to SFML.
-
No, I made a mistake, I have gnome 3.18. ::)
-
I can reproduce the problem in every SFML programs (tested with SFGUI examples).
-
Are you using the library provided through the package or your own self-built library? If you are using the package, can you try to build SFML yourself and test with that?
-
I'm using the system packages. I'll try to build SFML 2.3.2 and latest asap.
-
Hi,
I'm having the same issue on Gnome 3.20 in arch linux. It happens with every SFML app. I'm using 2.3.2 from the official repos.
-
This is definitely an issue from the SFML side, not Gnome. Tested SDL, GLFW and Allegro apps, none of them triggers this.
-
After a small research in IRC with the help of a mutter developer I found out below.
* Gnome window manager decides a window is unresponsive if the ping timesout as seen here: https://git.gnome.org/browse/mutter/tree/src/core/display.c#n2210
* A grep to SFML source shows that a pong sent back only in "close event" (if the comments are correct) and only in some special case: https://github.com/SFML/SFML/blob/master/src/SFML/Window/Unix/WindowImplX11.cpp#L1753
Keep in mind I know nothing about this I'm just hoping to narrow down the source of the problem. Please ignore if I'm not making any sense :D
Should I create a bug report on github?
-
There's already one: https://github.com/SFML/SFML/pull/947
Have you read all the information provided there first?
-
I didn't actually :o. From what I see that code went into 2.3.2 and the bug is still there so I'm guessing we need another bug report.
-
Are you sure that you're using SFML 2.3.2? Linux repos sometimes have older versions.
-
I will check when I have access to my linux machine
-
Actually, using master, I can reproduce this every now and then, and only if the window is in fullscreen mode.
The code that sends the pong back to the window manager is exactly identical to how everybody else (SDL, GLFW, etc.) also do it, and yet the window manager doesn't accept ours. It's also strange that this only happens with Gnome and only since recent versions. If I comment out the pong response, other window managers would also flag the application as unresponsive, so the code seems to be doing what it is meant to with other window managers.
I really have no idea what to do at this point. If anybody has contact to some Mutter developers, maybe they can also check if this might be some kind of regression. This is reproducible with the available packages and a really tiny amount of code, so it hopefully shouldn't cost them too much time.
-
I will try my luck in IRC.
That being said, I now see that arch linux has CSFML 2.3 in their repos not 2.3.2.
This is now my second time I come across a bug that is fixed in 2.3.2 and turns out I have CSFML 2.3 (the other one was "OpenGL extension SGIS_texture_edge_clamp unavailable" on windows).
The reason for that there is no precompiled binaries for people who uses Windows and there is no source tarball release for 2.3.2 so that distros can pacakge it. It's also extremely easy to mistake 2.3 for 2.3.2 in the website.
So can we get a 2.3.2 CSFML release pretty please ;D?
-
The reason there's no package is because there's no 2.3.2 CSFML version. But I'll try and see what needs to be done.
-
The reason there's no package is because there's no 2.3.2 CSFML version. But I'll try and see what needs to be done.
Unlike the windows shared libraries CSFML on linux doesn't seem to be statically linked with SFML so eventhough it's 2.3 I was using 2.3.2 effectively since that was the SFML version installed.
To make sure I've installed CSFML and SDML from git. Indeed the same problem persists and not only on fullscreen mode. Windowed mode is also affected. I'll make a new bug report for this.
-
Could you guys test the new bugfix/xlib branch (https://github.com/SFML/SFML/tree/bugfix/xlib)?
If you build SFML yourself, you might notice that the dependencies changed a bit.
Our continues integration system has also create Debian artifacts (http://www.sfml-dev.org/artifacts/by-branch/bugfix/xlib/) for the lazy people. ;)