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 2390 - Unresponsive Window on MinGW-W64 build
Summary: Unresponsive Window on MinGW-W64 build
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: x86 Windows 7
: P2 major
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-11 09:24 UTC by Nathaniel Fries
Modified: 2014-02-20 18:27 UTC (History)
2 users (show)

See Also:

Attachments
test program (1.04 KB, text/x-csrc)
2014-02-11 09:24 UTC, Nathaniel Fries 		Details
now calling SDL_PeepEvents in a loop (932 bytes, text/x-csrc)
2014-02-19 17:34 UTC, Nathaniel Fries 		Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Nathaniel Fries 2014-02-11 09:24:28 UTC 
Created attachment 1555 [details]
test program

I'm trying to use SDL built with MinGW-W64 using MSys, but the window is unresponsive.

My very simple test program is included.

The window is unresponsive, but the loop continues to run, as text continues to be added in the console window.
Comment 1 Andreas Ertelt 2014-02-19 13:28:13 UTC 
The problem is related to your loop. You only pull one event (out of possibly hundreds) from the queue every iteration (which includes console output, rendering and a delay every single time). Once the event queue is full the window cannot accept new events anymore and starts to "hang" which is Windows' way of saying "hey, that program cannot cope with the events I'm trying to send".

You should put the event processing into yet another loop and do the rendering after the queue was emptied or you've at least processed a decent number of events.
This is not an issue with SDL.
Comment 2 Gabriel Jacobo 2014-02-19 13:58:38 UTC 
I agree. Marking as invalid, if you fix the test case according to Andreas comments and you still get unresponsiveness, feel free to re open.
Comment 3 Nathaniel Fries 2014-02-19 17:34:47 UTC 
Created attachment 1563 [details]
now calling SDL_PeepEvents in a loop
Comment 4 Nathaniel Fries 2014-02-19 17:39:28 UTC 
Lost my comment there. I fixed the loop as suggested, removed the printing (it didnt identify the problem), still experiencing the hung app window.

It takes a delay of 5 seconds to cause Windows to recognize an app window as hung. Your explanations could not have caused the hung app window status ["(Not Responding)" in title bar] to begin with. It doesn't seem to respond to input at all.
Comment 5 Gabriel Jacobo 2014-02-19 17:43:47 UTC 
Ok, thanks for the update. I'm reopening the ticket.
Comment 6 Andreas Ertelt 2014-02-20 11:57:34 UTC 
You're also lacking a call to SDL_PumpEvents() before your loop. See last sentence in the remarks section of: http://wiki.libsdl.org/SDL_PumpEvents

There's also a vague mention of this in http://wiki.libsdl.org/SDL_PeepEvents Without this call (which is not implied using SDL_PeepEvents) messages do not get removed from the window's message queue (not to be confused with the queue SDL has).

An alternative if you do not need the advanced functionality would be using SDL_PollEvent() instead.
Comment 7 Nathaniel Fries 2014-02-20 18:20:14 UTC 
Been using Windows API directly instead of SDL for too long. Sorry about the non-bug report.
Comment 8 Gabriel Jacobo 2014-02-20 18:27:05 UTC 
No worries :)