2
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ And where do you have those problems? \$\endgroup\$ – wondra Sep 1 '14 at 16:21
  • \$\begingroup\$ There's no problem, I'm just curious as to why this usually takes quite some time for a seemingly simple transition. \$\endgroup\$ – Moritz Gunz Sep 1 '14 at 18:16
5
\$\begingroup\$

There are multiple points that come into play:

  1. 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.

  2. As a result of #2, some assets may need to be reloaded which takes time.

  3. 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.

\$\endgroup\$
  • \$\begingroup\$ In addition, if the resolution is changed, the monitor may also take a while to do the actual switching. On my machine this is the major factor when it comes to switching from windowed to fullscreen with a non native resolution. \$\endgroup\$ – rioki Sep 2 '14 at 13:15
2
\$\begingroup\$

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).

Taken from MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/bb174714%28v=vs.85%29.aspx#Resources

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.

\$\endgroup\$
-1
\$\begingroup\$

In a game it needs to re-render all the things on screen, it also needs to recalculate the position on screen... Stuff like that. In a "simple" app, it just re-draws some stuff (buttons, text-fields...), and it's done. I think that may answer your question.

\$\endgroup\$
  • 2
    \$\begingroup\$ A game continuously recalculates the positions of things on screen, but it does it in real time. Why would changing resolutions make it take so much longer? \$\endgroup\$ – Seth Battin Sep 1 '14 at 19:52
  • \$\begingroup\$ Because at higher resolution it needs to redraw more pixels. For example, it redraws 640*480 pixels at windowed mode, but at fullscreen it needs to redraw 1920*1080. And (as far as I know), some games re-calculate position of object on screen only if some change happens, like if player moves camera. However, as you may think, I may have missed some information and thus I may be completely wrong. \$\endgroup\$ – Mr. Nerd Sep 5 '14 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.