Bonjour je me posais la question de la différence de performance lorsqu'un jeux tourne en plein écran et en fenêtré. A quoi est dû la lenteur en mode fenêtré et est-ce qu'il y a un moyen d'améliorer les performances ?
Merci
Version imprimable
Bonjour je me posais la question de la différence de performance lorsqu'un jeux tourne en plein écran et en fenêtré. A quoi est dû la lenteur en mode fenêtré et est-ce qu'il y a un moyen d'améliorer les performances ?
Merci
La lenteur est du au fait que windows doit gérer pas mal de chose en plus en mode fenêtré: affichage du bureau, gestion de la fenêtre, du menu, etc...
Lenteur.. tout est relatif (tu peux largement atteindre les centaines de fps en mode fenêtré, beaucoup de gens jouent à World of warcraft ou autres jeux dans une fenêtre sans problème).
Après c'est clair, que si tu cherches à grapiller les millisecondes (pour un rendu vidéo ultra haut débit sans tearing/dropped frames par exemple) le plein écran (mode exclusif/discard) s'impose.
Tout dépend bien entendu de la plateforme sur laquelle tu travailles mais pour résumer :
- le mode plein écran exclusif fonctionne par flipping et non par blitting. C'est à dire que le contenu du backbuffer est directement lu par le convertisseur numérique vers analogique (DAC), le passage d'un backbuffer à l'autre se fait par un simple changement de pointeur dans le DAC. Si tu ne rendais rien, le flipping pourrait facilement se faire à des millions/milliers de frames par secondes (chose qui était exploitée par certaines vieilles plateformes dans les années 80/90 pour augmenter les capacités d'affichage par défaut). En pratique c'est un peu moins parce qu'il y a un peu d'overhead CPU à la fonction Present(). Par ailleurs c'est le seul mode qui garantit un rendu avec vertical sync sans déchirement (tearing). Ceci quand le passage d'un pointeur à l'autre est synchronisé avec la vitesse de rafraichissement de l'écran (60 trames par secondes par ex).
- Le mode fenêtré est généralement géré par blitting. Le blitting consiste à copier les bits (blt = bit block transfer) de ton backbuffer directement dans la surface affichée à l'écran qui ne bouge pas de place (aussi appelée surface primaire). C'est celle qui affiche le bureau. Le blitting peut-etre plus ou moins compliqué mais surtout il fait intervenir un mode compatibilité qui se doit d'opérer dans un environnement multi-tâches. Par exemple le vertical sync, à la place d'être garanti, devient un "best effort". Tout simplement parce que déplacer des bits peut se faire pendant la periode de transition de l'écran (sur une plateforme rapide et avec une résolution raisonnable), mais tu ne peux le garantir que pour une seule fenêtre et sans surimpression (overlapping). De plus les commandes de blits sont une copie plus ou moins rapides ce qui va limiter la vitesse maximale à laquelle tu peux afficher ta fenêtre (plus la fenêtre est grande, plus c'est lent).
- Sous Vista avec le mode Aero Glass (desktop accéléré par la carte graphique), c'est un mix entre flipping et blitting. Les backbuffer sont blittés sur la surface primaire, mais la surface primaire est flippée (en double ou triple buffering) pour limiter le tearing et autres défauts d'affichages (visibilité du contenu d'une fenêtre pendant son retracé etc).
- Un autre mode hybride existe : c'est le mode overlay qui est utilisé pour les vidéos dont j'ai parlé plus haut. Comme le blitting n'est pas forcément efficace et n'elimine pas le tearing, il y a la possibilité d'avoir une surface "superposée" à la surface primaire, appelée overlay, cette surface est "flippée" comme en plein écran mais ne s'affiche que sur une sous partie de l'écran (défini par un rectangle) et généralement masquée par les fenêtres en superposition. Ceci fonctionne par l'existence d'une clé de visibilité (colorkey) qui va dire au DAC : Si le pixel de la surface primaire est de cette couleur alors je veux que ce soit la surface overlay qui soit visible à la place. C'est aussi utilisé par certaines cartes haut de gamme en mode OpenGL pour qui le mode openGL fenetre est important.
LeGreg
Merci pour ces explications très interressante.
Je reviendrais sur un point, quand tu parle de "grapiller les millisecondes" j'ai fait quelques tests et le jeu que je développe tourne à 400 fps en moyenne en mode fenetré et 700 fps en plein écran. Ca fait une grosse différence quand meme.
Mais c'est vrai que pour l'instant mon jeu n'a ni texture ni détails, je vise les 60 fps à terme. D'apres ce que tu dis et ce que j'en comprend le rapport entre vitesse en plein écran et vitesse en fenetré devrait diminuer à mesure que j'ajouterai des détails, est-ce exact ?
les maths aident un peu :
700 fps : 1.43ms par frame
400 fps : 2.5ms par frame
Donc non ça ne fait pas une si grosse différence dans ton cas (surtout que le cout de Present() reste constant par frame, et n'est pas multiplié par la complexité de la scène à afficher !).
Dans un sens ou dans l'autre ça fait toujours a peu pres 2 fois plus... mais tu veux surement dire qu'il n'y a qu'une milliseconde de différence et que ce sera pareil quand ma framerate sera à 60 et que donc la différence en fenétré sera négligeable ?Citation:
700 fps : 1.43ms par frame
400 fps : 2.5ms par frame
bravo ! 8-)
Je sens un peu d'ironie dans ce BRAVO... C'était pour être sûr, aller je marque le tpic comme résolu !
J'ai déjà intervenu maintes fois là dessus.Citation:
Envoyé par supergrey
Un jeu fenêtré tournera plus lentement parce qu'une fenêtre doit capter les messages Windows ou du moins assurer une plus grande gestion des messages Windows.
En plus de cela le GDI, le DesktopWindows,l'interface utilisateur (user32.dll) doit la repeindre et la mettre à jour.
Cela sous entend que dans la mémoire vidéo, l'OS doit dessiner dedans toutes les fenêtres du Desktop ( bureau Windows ) contrairement au FULLSCREEN où ce sont tes DirectDrawSurface qui occupent la mémoire vidéo.
Il faut faire l"analogie entre les surfaces DirectDraw ou Direct X sur lesquelles on dessine même avec Direct3d et la mémoire vidéo du temps de ms-dos sur laquelle on dessinait en assembleur.
C'est logique, si sur ton écran tu as les icones du bureau, les fenêtres d'autres applications ,le bureau,les Themes,la barre des tâches tout cela doit être dessiné dans la mémoire vidéo et rafraichi constamment.
Une fenêtre = thread pour l'OS donc l'OS doit commuter entre toutes les tâches ce qui sollicite le CPU.
C'est pour cela que utiliser SDL ( sous Windows je m'entends parce que sous X-Window c'est différent et je ne connais pas) avec des libs comme Qt par exemple ou autre je n'en vois aucun intérêt car l'accélération matérielle sera minime.
Ah non je regrette la différence est flagrante et les jeux sont vraiment plus lents en mode fenêtré.Citation:
Envoyé par LeGreg
C'est pour cette raison que SDL par exemple sera plus lente...
Peut-être que tu as un 8 cores avec 8 Giga de RAM et une carte vidéo de 786Mo ? :mrgreen: