SFML community forums
Help => Window => Topic started by: Wizzard on March 29, 2011, 04:58:05 am
-
In Windows, my window stops doing display updates while being dragged. When dragged outside of the visible desktop and back, the window gets anomalies such as this (http://i.imgur.com/baeO4.png) from this (http://i.imgur.com/M094M.png). I'd prefer the application didn't create these anomalies in order to be consistent with other Windows applications. How do I get this to stop happening?
-
This is technically impossible to handle due to the way Windows handles this. Well, there's a workaround actually, which consists of handling events in a separate threads so that rendering is not blocked.
-
My main concern is that other applications don't do this. I want SFML to conform to the native look and feel.
-
I've explained this problem many times on this forum, maybe you could first see if you can find one of these topics before I explain it one more time ;)
-
Thanks for the responses. I've read one of the older threads found here (http://www.sfml-dev.org/forum/viewtopic.php?t=1090). I see the difficulty of remedying this now, but I'm still bugged by it. If get to patching SFML with callbacks and multi-threaded events, I'll post my results for anyone who's interested.
-
You can have a simple workaround on application side, there's no need to patch SFML. Just move GetEvent() to a separate thread.
-
You can have a simple workaround on application side, there's no need to patch SFML. Just move GetEvent() to a separate thread.
Instead of moving GetEvent to another thread, can we move the display part ? (Otherwise he won't be able to make SFML work on OS X as expected.)
-
It doesn't matter, just have GetEvent and what-you-don't-want-to-be-frozen in two separate threads.
-
OK, so I would recommend to draw in another thread as this works fine on OS X. :)
-
I'm glad that I can do this on the application side. Thanks for the input on OS X as well. I have a few questions though about accessing a single sf::Window instance from two threads:
1.) Do I have to use sf::Mutex to exclude my rendering (and logic) threads' access to my sf::Window's sf::Input while my event thread is calling sf::Window::GetEvent?
2.) Do I have to ensure that sf::Window::Close is not called on the sf::Window instance while the event thread is calling sf::Window::GetEvent?
3.) Is there any other functions I shouldn't call from other threads while the event thread is calling sf::Window::GetEvent? (ex. sf::Window::GetFrameTime)
-
The only functions that you cannot call in parallel to GetEvent are Close and Create (ie. those that change the internal window pointer). Everything else should be ok.