Author Topic: Window not updating display while being dragged (Read 5276 times)

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 from this. 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?

Laurent · « **Reply #1 on:** March 29, 2011, 07:47:02 am »

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.

Wizzard · « **Reply #2 on:** March 29, 2011, 02:00:17 pm »

My main concern is that other applications don't do this. I want SFML to conform to the native look and feel.

Laurent · « **Reply #3 on:** March 29, 2011, 02:04:59 pm »

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

Wizzard · « **Reply #4 on:** March 29, 2011, 02:36:41 pm »

Thanks for the responses. I've read one of the older threads found here. 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.

Laurent · « **Reply #5 on:** March 29, 2011, 03:19:52 pm »

You can have a simple workaround on application side, there's no need to patch SFML. Just move GetEvent() to a separate thread.

Hiura · « **Reply #6 on:** March 29, 2011, 09:27:32 pm »

Quote from: "Laurent"

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.)

Laurent · « **Reply #7 on:** March 29, 2011, 10:59:30 pm »

It doesn't matter, just have GetEvent and what-you-don't-want-to-be-frozen in two separate threads.

Hiura · « **Reply #8 on:** March 29, 2011, 11:04:26 pm »

OK, so I would recommend to draw in another thread as this works fine on OS X.

Wizzard · « **Reply #9 on:** March 30, 2011, 02:44:42 am »

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)

Laurent · « **Reply #10 on:** March 30, 2011, 07:42:34 am »

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.