Slow execution on first start.

[Perde]

[edit] The problem seems to have disappeared after updating to the latest snapshot. Should've thought of that before. While it would still be interesting to know what caused that behaviour, everything seems to work now.


This is something that has been bugging me for a very long time now, but never to a point that made me look for a solution. Whenever I start up a program that uses the SFML for the first time after a fresh boot the execution is terribly slow. I often get around 1fps, or even less.
Then, after ending the program and restarting it again, everything works perfectly fine (every other program that is using SFML works fine after that as well).
After the next reboot of my system however, the whole issue starts again.

It's probably caused by something else than SFML, but only happens with apps using it.
I'm currently using the RC and it's pre-compiled libs. OS is Win7 64 bit, gcc is 4.4.1 if I'm not mistaken.

Would be glad about any hint.

[eXpl0it3r]

Well this has nothing to do with SFML, just that you experience that problem with it...
It must be some OS related DLL/runtime loading/caching thing, I've never experienced such a thing on my Windows 7 box, than again I rarely reboot my system since hibernation & standby are much more convinient.
Have you ever tried application with SDL or other graphics libraries, or just games with similar problems?

[TheVirtualDragon]

Does it also happen with apps not using graphics? Like when only using the system module?

[Perde]

Nope, I have never used SDL and alike, and I've only written console-apps before hearing about SFML. I also have never experienced that problem or anything similar with any other game or application.

It just reminded myself that I've always been using static linking, in case that might be a part of the problem.

@TheVirtualDragon
I will test that right away.

[Perde]

I hope a one-time double-post is okay to bump the thread.

http://en.sfml-dev.org/forums/index.php?topic=8970.msg60382;boardseen#new
This thread just helped me narrow it down to the event-handling.
If I remove the event-loop (and reboot the system) the probelm doesn't occur anymore.
(I wonder why I never thought of that before)

Quite interesting to see, but I'm still as helpless as I was before.

[edit]
Now that I know it's linked to events I can tell you that the probelm is present either in bigger apps that make heavier use of events and also testing apps that only contain event-loops like this:

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