You can probably work backwards from the KB article to the underlying problem.
This is listed as a workaround:
"Configure the value of the DelayedDesktopSwitchTimeout registry entry. This value determines the time-out interval of a session before Windows 7 or Windows Server 2008 R2 switches between sessions."
In Windows, the login screen and user desktops run in different window manager sessions. There's a similar KB article that explains this in a little more detail:
"This issue occurs because the logon process runs in session 0. However, the logon script process runs in a different session. A 30-second delay occurs before Windows Vista switches from session 0 to another session. When the logon script interacts with you before the logon script process is complete, you have to wait for the 30-second time-out interval of session 0. To fix this problem, change the time-out interval to less than 30 seconds."
The login scripts in Windows run before the user's desktop appears. It seems reasonable that there's a trigger sent from a process that runs after the login script terminates that tells the OS to switch from session 0 to the new user's session. This is likely to prevent the desktop from flickering between the different login states.
In case there's a problem with logging in that wasn't expected, there's a failsafe timer, defaulting to 30s (hence the 30s login delay in both KB articles) that triggers the switch from session 0 regardless of the login state.
Given that, and the reference to stopping the "Desktop Window Manager Session Manager" in the linked KB, I would imagine that the solid-color desktop interferes with the login process by either crashing the service that renders the background, therefore failing to send the appropriate trigger or triggers a different code path that fails to send the signal.
Random idea: they might be using a single pixel "image" that they generate in memory, and then handing that image to their tiling routine, which duplicates and tiles it all over the massive resolutions we use today. Back in the day, using small tiling images on webpages was discouraged because slower computers/browsers would take forever to render them, even though they were simplistic in appearance.
According to the article, using a solid-colored image for the background is actually a workaround for the problem.
The fact that the symptom is a hard 30-second delay independent of processor speed, resolution, or graphics card suggests that the computer is not actually chugging through anything.
I've never used Windows 7, but does anyone know if there's any kind of... auto-pretty-ficiation stuff that it might be trying to do? Like, trying to center the image on the "most interesting" part of it or something like that?
I moved my main desktop to Win7 this last weekend, I'm going to guess it has something to do with a untested edge case in the logic that rotates wallpapers in the background.
There is a concept of themes, and part of that is rotating background images.
And they auto-translate the website to the language of the browser. So if yo happen to access the page with e.g. de_DE as preferred language, they sound like complete morons.
This is listed as a workaround:
"Configure the value of the DelayedDesktopSwitchTimeout registry entry. This value determines the time-out interval of a session before Windows 7 or Windows Server 2008 R2 switches between sessions."
In Windows, the login screen and user desktops run in different window manager sessions. There's a similar KB article that explains this in a little more detail:
http://support.microsoft.com/kb/940452
"This issue occurs because the logon process runs in session 0. However, the logon script process runs in a different session. A 30-second delay occurs before Windows Vista switches from session 0 to another session. When the logon script interacts with you before the logon script process is complete, you have to wait for the 30-second time-out interval of session 0. To fix this problem, change the time-out interval to less than 30 seconds."
The login scripts in Windows run before the user's desktop appears. It seems reasonable that there's a trigger sent from a process that runs after the login script terminates that tells the OS to switch from session 0 to the new user's session. This is likely to prevent the desktop from flickering between the different login states.
In case there's a problem with logging in that wasn't expected, there's a failsafe timer, defaulting to 30s (hence the 30s login delay in both KB articles) that triggers the switch from session 0 regardless of the login state.
Given that, and the reference to stopping the "Desktop Window Manager Session Manager" in the linked KB, I would imagine that the solid-color desktop interferes with the login process by either crashing the service that renders the background, therefore failing to send the appropriate trigger or triggers a different code path that fails to send the signal.