Video window hangs on Windows XP

SDL Development
1

Hi everyone,

I’m attempting a Windows port of a program I have originally written for
Linux, by using mingw + gcc 3.2 + pthread-win32 + libsdl 1.25. I managed
to compile run the program successfully, but when I set a windowed video
mode, Windows XP thinks the window is frozen and displays “Not
responding” on the title bar, even if I am drawing to the surface and I
see what I expect. I cannot move the window (an hourglass cursor appears
when I move the mouse pointer over the window), but I get everything
drawn onto the surface and the keyboard responds correctly. I am
initializing SDL as follows:

int InitSDL(int videoWidth, int videoHeight)
{
if(SDL_Init(SDL_INIT_VIDEO) < 0)
{
fprintf(stderr,
“Could not initialize SDL: %s\n”, SDL_GetError());
return 0;
}

SDL_WM_SetCaption("Video Device", " ");

if(!SDL_VideoModeOK(videoWidth, videoHeight,
    SCREEN_DEPTH, SDL_SWSURFACE))
{
    fprintf(stderr,
        "Video mode not supported: %s\n", SDL_GetError());
    return 0;
}

if((screen = SDL_SetVideoMode(videoWidth, videoHeight,
    SCREEN_DEPTH, SDL_SWSURFACE)) == NULL)
{
    fprintf(stderr,
        "Could not set video mode!: %s\n", SDL_GetError());
    return 0;
}

InitColorPalette();

/* if(SDL_EnableKeyRepeat(700, 700) < 0)
{
fprintf(stderr,
“Could not set keyboard values!: %s\n”, SDL_GetError());
return 0;
}
*/
return 1;
}

I am using the windows 1.25a version of the SDL runtime DLL, not the DLL
I compiled myself on MinGW. Any help would be much appreciated.

Best Regards,–
Claudio Alvarez

2

Hi everyone,

I’m attempting a Windows port of a program I have originally written for
Linux, by using mingw + gcc 3.2 + pthread-win32 + libsdl 1.25. I managed
to compile run the program successfully, but when I set a windowed video
mode, Windows XP thinks the window is frozen and displays “Not
responding” on the title bar, even if I am drawing to the surface and I
see what I expect. I cannot move the window (an hourglass cursor appears
when I move the mouse pointer over the window), but I get everything
drawn onto the surface and the keyboard responds correctly.

That usually happens when you don’t run the SDL event loop.
(e.g. SDL_PollEvent() or SDL_WaitEvent())

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

3

I have discovered the problem relates to event handling. The main
process of my app initializes the SDL environment (the 240x160x8bit
surface window I need) and then a pthread-win32 based thread handles
events separetely, specifically keyboard events. The thread seems to
handle keyboard events alright, and I get animation on the surface, but
since the thread handles all events, windows doesn’t seem to recognize
the user level pthread-32 thread as a valid task in order to know about
the whole process’ state, thus it assumes the whole process has frozen.
I can avoid freezing by making the main process wait for an event and
put the event back into the queue inmediatly (using mutex for access to
the event queue), however I think this is inefficient and unhealthy. Is
there any other more sane way to accomplish this??

Regards,

Claudio.--------------------------------------------------------------------------------------------

Hi everyone,

I’m attempting a Windows port of a program I have originally written for
Linux, by using mingw + gcc 3.2 + pthread-win32 + libsdl 1.25. I managed
to compile run the program successfully, but when I set a windowed video
mode, Windows XP thinks the window is frozen and displays “Not
responding” on the title bar, even if I am drawing to the surface and I
see what I expect. I cannot move the window (an hourglass cursor appears
when I move the mouse pointer over the window), but I get everything
drawn onto the surface and the keyboard responds correctly. I am
initializing SDL as follows:

int InitSDL(int videoWidth, int videoHeight)
{
if(SDL_Init(SDL_INIT_VIDEO) < 0)
{
fprintf(stderr,
“Could not initialize SDL: %s\n”, SDL_GetError());
return 0;
}

SDL_WM_SetCaption("Video Device", " ");

if(!SDL_VideoModeOK(videoWidth, videoHeight,
    SCREEN_DEPTH, SDL_SWSURFACE))
{
    fprintf(stderr,
        "Video mode not supported: %s\n", SDL_GetError());
    return 0;
}

if((screen = SDL_SetVideoMode(videoWidth, videoHeight,
    SCREEN_DEPTH, SDL_SWSURFACE)) == NULL)
{
    fprintf(stderr,
        "Could not set video mode!: %s\n", SDL_GetError());
    return 0;
}

InitColorPalette();

/* if(SDL_EnableKeyRepeat(700, 700) < 0)
{
fprintf(stderr,
“Could not set keyboard values!: %s\n”, SDL_GetError());
return 0;
}
*/
return 1;
}

I am using the windows 1.25a version of the SDL runtime DLL, not the DLL
I compiled myself on MinGW. Any help would be much appreciated.

Best Regards,

–
Claudio Alvarez

4

I have discovered the problem relates to event handling. The main
process of my app initializes the SDL environment (the 240x160x8bit
surface window I need) and then a pthread-win32 based thread handles
events separetely, specifically keyboard events. The thread seems to
handle keyboard events alright, and I get animation on the surface, but
since the thread handles all events, windows doesn’t seem to recognize
the user level pthread-32 thread as a valid task in order to know about
the whole process’ state, thus it assumes the whole process has frozen.
I can avoid freezing by making the main process wait for an event and
put the event back into the queue inmediatly (using mutex for access to
the event queue), however I think this is inefficient and unhealthy. Is
there any other more sane way to accomplish this??

Welcome to windows. :slight_smile:
Seriously, having the window thread process windows messages is the only
way I know of to let Windows know that the application is alive. In fact,
in windowed mode, I’m pretty sure that only the thread that created the
window can recieve messages about that window.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment