We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2316

Summary: Application get stuck in SDL_PumpEvents while moving or resizing window.
Product: SDL Reporter: Andreas Ragnerstam <andreas.ragnerstam>
Component: eventsAssignee: Sam Lantinga <slouken>
Status: RESOLVED DUPLICATE QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: BurnSpamAddress, nafiepoo
Version: 2.0.1   
Hardware: x86_64   
OS: Windows 7   

Description Andreas Ragnerstam 2013-12-18 15:22:33 UTC
On Windows; While I move around or resize a window, SDL will get stuck in the SDL_PumpEvents function and not return until the window is released.

Not sure if it is possible to work around this or if is a limitation in Windows, but I would like the application to be able to run while I am moving the window.
This problem exists in both SDL 1.2 and 2.0.1.

I did something similar to the following to determine that I was stuck in SDL_PumpEvents and it would not print the second message until the window was released:

printf("Entering Pump Events\n");
SDL_PumpEvents();
printf("Done pumping events\n");
Comment 1 BurnSpamAddress 2014-01-04 02:51:38 UTC
This is a well known issue on Windows. Whenever a window is moved or resized, a modal wndproc takes over and events are not delivered to the application until the move/resize process is complete.

A partial solution exists: listen for WM_NCBUTTONDOWN messages and install a timer to periodically pump events until WM_NCBUUTONUP. This works, but there is an unavoidable ~300ms delay until WM_NCBUTTONDOWN is delivered (windows is presumably delaying delivery in order to detect double click events.)

You can see this in action in many many windows applications, for instance the new Visual Studio 2012/2013 installer. Watch its animations while you click and drag its window - you get a ~300ms delay where the stop, before starting to move again.

When using OpenGL, you can move the OpenGL context to a separate thread in order to continue rendering while the window is being moved/resized. You will still miss the mouse/keyboard events, but your rendering will continue working smoothly.
Comment 2 Nathaniel Fries 2014-01-20 16:48:16 UTC
This is a duplicate of bug 2077. Also, I posted a link to some code which would resolve this issue on bug 2077.

*** This bug has been marked as a duplicate of bug 2077 ***