Texture::update() - problème de durée

[gostron]

Bonjour,

J'avais déjà posté un problème concernant des problèmes de durée sur le setActive() de sf::RenderTexture (en croyant que ça venait du clear() ), j'étais donc parti sur une autre méthode pour effectuer mon éclairage, qui était de draw toutes les lumières en additif, puis de sauvegarder l'image et de la draw en multiply pour l'effet de luminosité.

Pour sauvegarder l'image, je la stocke dans un object Texture en appelant le

myTexture.update(window);

Le problème, c'est que j'observe des problèmes de latence également. Voici le code minimal :

int main()
{
    sf::Texture * _texture = new sf::Texture();
    _texture->create(1280, 720);

    sf::Window window(sf::VideoMode(1280, 720), "My window");

    // on fait tourner le programme jusqu'à ce que la fenêtre soit fermée
    while (window.isOpen())
    {
        // on inspecte tous les évènements de la fenêtre qui ont été émis depuis la précédente itération
        sf::Event event;
        while (window.pollEvent(event))
        {
            // évènement "fermeture demandée" : on ferme la fenêtre
            if (event.type == sf::Event::Closed)
                window.close();
        }
        sf::Clock myClock;
        _texture->update(window);
        qint64 time = myClock.restart().asMilliseconds();
        if ( time > 1 )
            qDebug() << "Update took too much time (" << time << "ms)";
    }

    return EXIT_SUCCESS;
}
 

et voici ce que j'obtiens en sortie :

Update took too much time ( 2 ms)
Update took too much time ( 2 ms)
Update took too much time ( 4 ms)
Update took too much time ( 4 ms)
Update took too much time ( 20 ms)
Update took too much time ( 4 ms)
Update took too much time ( 4 ms)
 

Sachant que ces messages arrivent relativement lentement (c'est-à-dire que la plupart des update() prennent moins de 1 ms.)

J'utilise Win 8, la version release de SFML 2.0 que j'ai recompilée et que j'utilise en static et je compile à l'aide de QtCreator.

Dites-moi si j'oublie quelque chose

[Laurent]

Il y a un sujet sur le forum anglais, avec un mec qui constatait des pics dans le temps de rendu, et qui avait debuggé comme un malade pour trouver d'où ça venait. Si je me souviens bien, ça avait un rapport avec les appels à glGet. Donc ce que tu peux essayer : commenter tous les appels à glGet (ils ne sont pas nécessaires au bon fonctionnement dans ton cas), recompiler SFML, et refaire tes tests (y compris avec sf::RenderTexture, qui est tout de même la bonne solution à la base). Pense à bien être en Release quand tu testes.

Si jamais tu arrives à retrouver le sujet correspondant sur le forum anglais, il y a plein de choses intéressantes à apprendre dedans.

[gostron]

Tout d'abord merci pour la réponse rapide encore une fois

J'ai bien retrouvé le post anglais, il est en effet très intéressant mais dépasse de loin mes connaissances actuelles ^^ Je vais prendre le temps de bien tout comprendre et de voir ce que je peux faire.

Il me semble avoir compris cependant que l'instabilité observée pouvait être dûe à m_context et qu'il avait résolu son souci en le remplaçant directement par le code openGL qui va bien.

Je posterai une suite si j'ai davantage d'informations quant à mon souci.

[gostron]

J'ai testé la mise en commentaire de certains bouts de code openGL dans la SFML (dans Texture::update() pour le cas) mais même en commentant tout, j'obtiens des résultats des plus étonnants ! La fonction vide met parfois  entre 2 et 4 ms à s'exécuter si on suppose la clock exacte.

Avec ces résultats trop surprenants pour venir de la SFML, j'ai mis ma clock autour de la boucle événementielle également, et là...

Update took too much time ( 3 ms)
Update took too much time ( 3 ms)
Update took too much time ( 5 ms)
Update took too much time ( 11 ms)
Update took too much time ( 11 ms)
Update took too much time ( 11 ms)
Events took too much time ( 10 ms)
Update took too much time ( 11 ms)
Update took too much time ( 10 ms)
Update took too much time ( 11 ms)

Quelques petites millisecondes pour Texture::update() puis un ensemble trop important pour les deux...

Dans mon vrai programme il arrivait également que les événements prennent 30ms à être traités ou même n'importe quel élément pouvait prendre du temps pendant certaines frames.

J'ai peur que cela vienne uniquement de mon ordinateur et qu'il est temps de changer la carte mère.

Je pense que le sujet est clos :s


Le code :

int main(int argc, char *argv[])
{
    sf::Texture * _texture = new sf::Texture();
    _texture->create(1280, 720);
    qint64 time;

    sf::Window window(sf::VideoMode(1280, 720), "My window");

    // on fait tourner le programme jusqu'à ce que la fenêtre soit fermée
    while (window.isOpen())
    {
        sf::Clock myClock;
        // on inspecte tous les évènements de la fenêtre qui ont été émis depuis la précédente itération
        sf::Event event;
        while (window.pollEvent(event))
        {
            // évènement "fermeture demandée" : on ferme la fenêtre
            if (event.type == sf::Event::Closed)
                window.close();
        }

        time = myClock.restart().asMilliseconds();
        if ( time > 1 )
            qDebug() << "Events took too much time (" << time << "ms)";

        _texture->update(window);

        time = myClock.restart().asMilliseconds();
        if ( time > 1 )
            qDebug() << "Update took too much time (" << time << "ms)";
    }

    return EXIT_SUCCESS;
}

[Laurent]

Pour faire du profiling efficace tu devrais utiliser un profiler. Méfie-toi des tests trop simplistes sans les outils adéquats. Et il se peut même que qDebug() prenne déjà un temps significatif par rapport à ce que tu mesures.

Je te conseille VerySleepy, il est étonnament facile à utiliser (tu le lances, tu lui dis quel processus et quel thread surveiller, et pof il te sort le résultat en temps réel -- et pas besoin de recompiler ton projet avec des options particulières).