I'm not sure whether this is the correct site to ask this question, but why does it sometimes (game-specific, usually) take really long to enter / exit a fullscreen game (black screen for ~1-5s)? And why don't we have these problems for example when entering a Windows 8 fullscreen app?
There are multiple points that come into play:
Switching from windowed to full-screen mode often involves recreating some rendering / drawing contexts which simply needs some time to do some "administrative" tasks, such as allocating memory. This may also involve finding a matching resolution that works (e. g. see the documentation for this D3D9 method) plus the time the monitor itself needs to adjust internally to this new set resolution.
As a result of #2, some assets may need to be reloaded which takes time.
Finally, based on the new rendering contexts and the assets, the scene needs to be rendered again. The rendering itself should not take long [*] but the setup might, for example if a complete scene-graph systems needs to be repopulated from the previous state.
[*] On the one hand, full screen mode usually involves more pixels to be rendered on. On the other hand, an application running in full-screen mode has a more exclusive/direct access to the rendering devices, which should speed up things again. See also this answer on Arcade.SE. All depends on the application and the chosen screen resolution, but in the end should play no major role for the actual switching time between the two states.
I would say that the most time-consuming task that needs to happen in most games is recreating video memory resources (textures, render targets, meshes) in response to a "device lost" event (note that this is specific to Direct3D 9 and earlier).
The device makes a transition to the lost state when an event, such as the loss of keyboard focus in a full-screen application, causes rendering to become impossible. (...) A lost device must re-create resources (including video memory resources) after it has been reset. (...) If the device can be restored, the application prepares the device by destroying all video-memory resources and any swap chains.
Direct3D 10+ applications don't have this concept of a lost device state, and avoid most of this bookkeeping work in the process, I believe by virtue of the fact that the WDDM implements "virtual memory" for video RAM. That might explain why you wouldn't see this behavior in Metro applications.