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 1595

Summary: One-second delay within SDL_SetVideoMode
Product: SDL Reporter: rgrocottbugzilla
Component: videoAssignee: Sam Lantinga <slouken>
Status: RESOLVED ENDOFLIFE QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 1.2.15   
Hardware: x86   
OS: Windows 7   

Description rgrocottbugzilla 2012-09-06 16:56:45 UTC 
SDL_SetVideoMode takes around 1 second to return on my system. Since this delay occurs after the window is made visible, it makes client programs appear fairly laggy. Had a look at the source, and discovered that the delay is pathological, rather than a performance issue - practically all of it occurs within a single call to SetWindowPos, within DIB_ResizeWindow.

Couldn't track down the cause, but managed to narrow it down a little. If the call to SetWindowPos is decomposed into calls to MoveWindow, ShowWindow (with SW_SHOWNA) and SetActiveWindow, all of the delay occurs within SetActiveWindow. As far as I can tell, the delay doesn't occur within a window message handler. The last message handled before the delay is WM_ACTIVATE, and the first message afterwards is WM_IME_SETCONTEXT.

This error occurs within at least one other SDL program (the game Eversion), so I don't believe it's an error within my client code, and I haven't observed it in any non-SDL programs, so it's probably not caused by some third-party program blocking the window manager. The error still occurs if Aero Glass is disabled.

Interestingly, the first time (only) that any SDL program is launched after logging on, the bug is not present. No idea why this should be the case, since the original process is definitely terminated, calling SDL_Quit on its way out.
Comment 1 rgrocottbugzilla 2012-09-08 10:25:27 UTC 
Managed to reproduce this bug on a second machine, running a fairly vanilla installation of Windows 7, by running the videogame Eversion.

The bug was exactly the same, except that (barring some kind of stupid oversight on my part) the bug occured the very first time that I ran the program after downloading it. This seems to rule out the possibility that SDL instances are somehow interfering with one another after being discarded.
Comment 2 rgrocottbugzilla 2012-09-09 09:24:33 UTC 
Managed to track down the cause. The bug can be solved by commenting out the first two calls to LoadKeyboardLayout in DIB_InitOSKeymap, in SDL_dibevents.c.

Apparently, switching keyboard layouts is known to be very slow, under Windows 7 only. Since hLayoutUS doesn't seem to be used except as an (unnecessary?) argument to MapVirtualKeyEx, this bug could be solved by completely gutting the layout-loading code, and just going with the user's current layout.

If this isn't possible, I believe that ActivateKeyboardLayout loads a keyboard layout synchronously. Doing this before the window is made visible will cause the delay to be much less evident to the user, although it would still delay the program's start by around 500ms.
Comment 3 Ryan C. Gordon 2015-08-25 09:38:23 UTC 
Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we _will_ accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.