Event polling in another thread than the main thread fails on MSWindows.
The window doesn’t react when not polling for events in the main thread. The window cannot be moved or resized and all visible screen blits/updates stops after some seconds, although the program is still running in the background, as if no polling takes place.
This issue coincides with another problem under MSWindows:
When moving or risizing a window, the main thread freezes until the mouse button is released, other threads don’t stop. This also means that event handling is not taking place in that time. When resizing the window graphical garbage becomes visible because the main thread cannot update/resize the screen when halted. Screen updates don’t halt when done by other threads, but they are unable to get any events from polling.
It is possible to update the screen within the event filters, which aren’t halted, but it can cause a crash when the main thread halted in a critical section.
A workaround to prevent any freezing would be to pass all events from an event filter to a user queue, which can be accessed by other threads. It needs some mutex measures but this way noting is halted. Nevertheless it makes the program design more complex and is difficult to add later, when not taking into account from the beginning. So it would be best, if libSDL could work around that issues itself by making the main thread a dummy and another thread to the actual libSDL main thread, which is able to poll for events.
I stumbled over this problems, because I’m trying to write a video player using SDL. Moving the window can bring audio/video out of sync, because audio callbacks don’t freeze (audio callbacks probably run in another thread). I don’t like seeing the video freeze when moving the window.
Is this described behavior the same on all versions of MSWindows?
I only tried Windows XP. It would be good to have some consistency in the behavior of SDL among different OSes.
Is there any intention to remove this issues for the MSWindows port of libSDL? If not, I request some notes about this in the libSDL docs.
These limitations are well known and documented, at least for SDL 1.2.
Windows requires event polling to be performed by the “main” thread.
This must be the thread that sets SDL_SetVideoMode(). Making this work
in a multi-threaded fashion, using a fake dummy thread would be
difficult and arguably not worth it. This limitation can usually be
gotten around by creating your own threads to do any heavy lifting,
and using the “main” thread for interactions with the window manager.
Given this, I assume there is no intention to work around this.
However, I imagine that if someone comes up with a patch then it will
certainly be considered, especially for SDL 1.3 where the API isn’t
tied down.
The issue with the window freezing during resize operations I am less
sure of. I know I found a “workaround”, more of a hack, where you
hijack the SDL_EventFilter to allow you to respond to resize events as
they occur, see here: http://www.gamedev.net/topic/428022-sdl-window-resize-glitch/
I honestly don’t know if this resize thing is a Windows limitation or
SDL architectural limitation, I’m not a Win32 programmer. I’d like to
know if it could be removed though.On 14 January 2011 17:56, tobby wrote:
Is there any intention to remove this issues for the MSWindows port of
libSDL? If not, I request some notes about this in the libSDL docs.
Event polling in another thread than the main thread
fails on MSWindows. The window doesn’t react when not
polling for events in the main thread. The window cannot
be moved or resized and all visible screen blits/updates
stops after some seconds, although the program is still
running in the background, as if no polling takes place.
You’re doing it wrong ;). On MSWindows, the actual windows themselves
are owned by the particular thread that created them (this is such a
fundamental thing that it’s even reflected in Microsoft’s COM: you can
register COM components as either single-threaded or multi-threaded
via the thread’s “apartment model”). If you think this is bad, then
think about MacOS: on the current versions of that, ALL I/O has to
take place in the main thread (including ALL windows), apparently
because the implementers couldn’t be bothered to make the portion of
the I/O system that’s actually loaded by applications safe for
multi-threading.
This issue coincides with another problem under
MSWindows:
When moving or resizing a window, the main thread freezes
until the mouse button is released, other threads don’t
stop. This also means that event handling is not taking
place in that time. When resizing the window graphical
garbage becomes visible because the main thread cannot
update/resize the screen when halted. Screen updates
don’t halt when done by other threads, but they are
unable to get any events from polling.
It is possible to update the screen within the event
filters, which aren’t halted, but it can cause a crash
when the main thread halted in a critical section.
A workaround to prevent any freezing would be to pass
all events from an event filter to a user queue, which
can be accessed by other threads. It needs some mutex
measures but this way noting is halted. Nevertheless it
makes the program design more complex and is difficult
to add later, when not taking into account from the
beginning. So it would be best, if libSDL could work
around that issues itself by making the main thread a
dummy and another thread to the actual libSDL main
thread, which is able to poll for events.
I stumbled over this problems, because I’m trying to
write a video player using SDL. Moving the window can
bring audio/video out of sync, because audio callbacks
don’t freeze (audio callbacks probably run in another
thread). I don’t like seeing the video freeze when
moving the window.
I suspect that all of these problems are because you’re trying to
update the window outside of the thread that created it, and actually
has absolutely nothing to do with events. That having been said, it
would probably be best to do the actual event access in the creating
thread as well.
Is this described behavior the same on all versions of
MSWindows?
Yes.
I only tried Windows XP. It would be good to have some
consistency in the behavior of SDL among different OSes.
It’s likely that the only reason you can do this sort of thing on
XWindows is because you’re sending your window manipulation events
over a filesystem handle, and when they’re received XWindows routes
them to the appropriate thread itself.
Is there any intention to remove this issues for the
MSWindows port of libSDL?
I’m certain the Microsoft is always willing to accept source code as
long as you give them all rights to it, but don’t bet anything on
getting it actually used ;).
I short, the problem isn’t SDL, the problem is that you’re trying to
do something that you should never try to do. Remember: restrict
display behavior to the initial thread and you should be fine.> Date: Fri, 14 Jan 2011 09:56:57 -0800
From: “tobby”
To: sdl at lists.libsdl.org
Subject: [SDL] SDL 1.2.14 MSWindows - event in another thread;
I honestly don’t know if this resize thing is a Windows limitation or
SDL architectural limitation, I’m not a Win32 programmer. I’d like to
know if it could be removed though.
This is an SDL implementation limitation.
@OP: Jared Maddox is right.------------------------
EM3 Nathaniel Fries, U.S. Navy