Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: 16 millisecondes pour un simple window.display qui n'affiche rien : normal?  (Read 7071 times)

0 Members and 1 Guest are viewing this topic.

aniwey

  • Newbie
  • *
  • Posts: 7
    • View Profile
Bonjour!

Cela fait longtemps que je n'ai pas utilisé la SFML et j'y reviens depuis peu pour un projet. Cependant je rencontre un problème : l'affichage me semble assez lent. Lorsque je fais un display() sur un renderWindow qui n'affiche rien, cela prend en moyenne 16 millisecondes. Quand quelque chose doit être affiché (un simple fond rouge), c'est alors très chaotique : entre 8 et 20 millisecondes par boucle d'affichage..

Voici le code minimal qui produit le problème :

#include <SFML/Graphics.hpp>
#include <iostream>

int main(void){
  sf::RenderWindow window(sf::VideoMode(800, 600), "test");
  sf::Clock clock;
  float a;

  a = clock.getElapsedTime().asSeconds();
  for(int i = 0; i < 100; ++i){
    window.display();
  }
  std::cout << clock.getElapsedTime().asSeconds() - a << std::endl;
}
 

Ce bout de code affiche des valeurs légèrement supérieures à 1.6 en moyenne, soit 1.6 secondes pour 100 affichages. Est-ce normal? Cela peut-il venir de mon ordinateur? (pas de carte graphique, chipset Intel, sur une archlinux mise à jour)

Merci d'avance!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
16 ms ça fait 60 fps. Est-ce que la synchro verticale ne serait pas activée dans les paramètres de ton pilote graphique ?
Laurent Gomila - SFML developer

aniwey

  • Newbie
  • *
  • Posts: 7
    • View Profile
Effectivement, ça a l'air d'être ça... En regardant le man de mon pilote ("man intel") :

       Option "SwapbuffersWait" "boolean"
              This option controls the behavior of glXSwapBuffers and glXCopySubBufferMESA calls by GL applications.  If enabled, the calls will avoid tearing by making sure the display scanline is outside of the
              area  to  be  copied  before the copy occurs.  If disabled, no scanline synchronization is performed, meaning tearing will likely occur.  Note that when enabled, this option can adversely affect the
              framerate of applications that render frames at less than refresh rate.

              Default: enabled.

Du coup, j'imagine qu'on ne peut pas contourner la chose sans demander aux utilisateurs de désactiver leur synchro verticale ou sans faire du threading? ^_^

Merci beaucoup en tout cas pour cette réponse rapide :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Oui, ce sont les utilisateurs qui décident de ce genre de paramètre.
Laurent Gomila - SFML developer