threads, events and windows

[lrx]

Hello
Again toying with fresh built sfml2rc I've encountered strange problem that was non existing in previous built(RC built on April 12th).
It might not be best practice but nonetheless this is what I am using at the moment:
Thread one - event pulling;
Thread two - drawing and calculating;
with old build of sfml everything ran smooth and fast. However with fresh one it seems like window is not "in focus" by default or something of sort and I have to click/hold on Title bar which will boost fps. After that clicking back and forth on different windows(chrome/VS) causes similar thing, although clinking away from window boosts fps and clicking into Drawing area of render window slaps it down.
this happens in "SFML-2.0-rc-69-ge4ea686" build on W7x64, in both VS10 and VS11 each with their own built ddls, most recent nVidia WHQL drivers. I can not confirm which release is the one that works fine, only date it was build on(and downloaded) - April 12th.

This does not happen if i put drawing in same thread as event pulling

Problem occurs with this code

#include <SFML/Graphics.hpp>

void Draw();

sf::RenderWindow window;

int main()
{      

        //Initialize window
        window.create(sf::VideoMode(1680, 1050),"");
        window.setActive(false);

        //thread for draw function
        sf::Thread RenderThread(&Draw);
        RenderThread.launch();

        //GameLoop
        while(window.isOpen())
        {
                //Event Handling
                sf::Event event;
                while(window.pollEvent(event))
                {
                        if(event.type == sf::Event::Closed)
                                window.close();
                        if(event.type == sf::Event::KeyPressed)
                        {
                                if(sf::Keyboard::isKeyPressed(sf::Keyboard::Escape))
                                        window.close();
                        }
                }
        }
        return 0;
}

void Draw()
{
        int counter = 0;
        int fps = 0;
        sf::Text fpsText;
        sf::Clock clk;
        sf::Font font;
        font.loadFromFile("corbel.ttf");
        fpsText.setFont(font);

        window.setActive(true);
        window.setVerticalSyncEnabled(false);
       
        while(window.isOpen())
        {
                counter++;
                if(clk.getElapsedTime().asSeconds()>=1)
                {
                        fps = counter/clk.getElapsedTime().asSeconds();
                        counter=0;
                        clk.restart();
                        std::string sss;
                        char tempB[20];
                        sprintf(tempB, "%d", fps);
                        sss = tempB;
                        fpsText.setString(sss);
                }
               
                window.clear();
                window.draw(fpsText);
                window.display();
        }
};
 

I know I am asking a lot of questions, but this really does bother me.

[eXpl0it3r]

It's okay to ask a lot of questions, so don't worry. ;-)

Hmmm it's funny how you actually know that it's not good to seperate even polling and drawing and you don't have any errors when not seperating them, but you refuse to not seperate them anyways...
Is there a reason why it has to work in your way?

If you don't poll events Windows will think that the window is not responding. I guess a similar effect can have the constant event polling, but I'm not quite sure.
Can you try to put a sf::sleep(sf::milliseconds(10)); function call after the event polling loop (game loop), so you give the CPU a break.
How many cores does your PC have? If it's only having one core (notice some CPU only use hyperthreading but show that they've two cores) then the constant event polling would slow down the other thread and by holding the titlebar you'd freeze the event polling thread, thus enabling the second thread to mind his buissness. So pausing the first thread every iteration will give the other thread more CPU time.

[Zephilinox]

none of that would make a difference, if it worked for him before on an older version of SFML2 then somethings changed since then to cause it.

[Laurent]

Have you updated your graphics drivers, or is SFML the only thing that changed?

You should indeed pause your event loop, so that it doesn't eat 100% of your CPU. Using the waitEvent function will be slightly better than using sf::sleep directly. It may not solve your problem, but it will help a lot.

[lrx]

none of that would make a difference, if it worked for him before on an older version of SFML2 then somethings changed since then to cause it.

Well eXpl0it3r reasoning is good, and putting sf::sleep(sf::milliseconds(10)); after event pulling does resolve the issue.
But that't only half of problme I made this post because I'm concerned if that's not some kind of bug, since it used to work.

@eXpl0it3r
I'm running on first gen i7 920 cpu therefore I have 4 cores and 8 threads.

It doesn't have to be setup that way, but from my previous tests with older build (which worked fine) it seemed like separating them actually increased fps by far(forgot number but it was noticeable). Which I figured was due to event pulling taking too much time, that's why I've put it into separate thread.
I am probably using threads wrong, since it is first time me ever attempting to use them, but still it is strange that something that worked stopped with new release.

@Laurent
SFML is the only thing that changed. My drivers are the same that used to be, just checked to confirm they are not outdated -  which they were not so I didn't install new/beta ones.
edit@Laurent I don't know where to put that window.waitEvent(event); where ever I put them they stop my events to be read correctly - I have to spam esc to exit and so on

Thanks for replies