Dragging the window causes display to stop updating

[ph03nix]

I'm using SFML 2.1 on Windows 7 and XP.

I noticed that when I click and draw the SFML window's title bar to drag the window around, the display stops updating until I release it. Is there a way to fix this?

[G.]

http://en.sfml-dev.org/forums/index.php?topic=4480.0

[ph03nix]

Is this from a different version of SFML? It says to put GetEvent on a seperate thread, but SFML 2.1 only has pollEvent.

Either way I tried putting pollEvent on a seperate thread, but the window locks up (can't drag, minimize, close) unless it's being called on the main thread.

I have a function like this:

int pollThread(){
       
        while (window.isOpen()){

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

And before I have the drawing loop in the main function I do this:

sf::Thread thread(&pollThread);
thread.launch();

[eXpl0it3r]

Yes that is SFML 1.6 code. I'm not sure, but could you try to poll the events in the thread you created the window and draw in a separate thread?

[ph03nix]

Yes that is SFML 1.6 code. I'm not sure, but could you try to poll the events in the thread you created the window and draw in a separate thread?

That worked. Thanks!

Although when I call window.create to recreate the window with a different style it crashes or malfunctions (in any of the threads)

[eXpl0it3r]

Well that's probably a sync issue. Writting multi threaded applications can be quite a challenge, since you'll nees to know how to make sure that the two threads don't try to access the same data at the same time (e.g. if one is changing a varianle and the other is reading it at the same time, the result is undefined).

So before you can recreate a window, you nesd to make sure the other thread isn't in the middle of using the window either.

Personally I wouldn't bother with events in a separated thread.

[ph03nix]

I'm making a rhythm game where the music syncs up to the gameplay, and dragging the display causes the game to become de-synchronized. I was previously using allegro, and dragging the display did not cause the game logic to stop.

[AlexAUT]

You could only handle the events in another thread when you are ingame, because there I guess you won't call window.create() . And in the menu/options you handle events in the main-thread to avoid raceconditions when you change the window.


AlexAUT