Messages

1

Fenêtrage / Re : Contextes OpenGL "internes" ?

« le: Octobre 09, 2013, 09:16:24 pm »

Je vois, merci pour ces indications

2

Fenêtrage / Contextes OpenGL "internes" ?

« le: Octobre 09, 2013, 08:24:52 pm »

Bonsoir,

Ce topic concerne une partie des sources de SFML.  Je suis très intéressé par le fonctionnement interne de la bibliothèque, dans un but purement pédagogique, et nous trouvons rarement des codes C++ aussi bien structurés que celui-ci

Ainsi, Je sonde les entrailles de SFML-Window afin de comprendre la création et la manipulation de contextes OpenGL sous X, avec GLX. La plupart du travail est effectué entre les classes WindowImpl et GLContext et leurs version Unix.

Dans la classe GLContext, je vois que SFML garde en RAM plusieurs contextes.

• Un context thread local ;
• Un contexte partagé partout ;
• Un contexte interne thread local ;
• Un ensemble de contextes internes

Histoire de les manipuler de l'un vers l'autre, ce sont tous des pointeurs (ou des sf::ThreadLocalPtr).

De ce que j'ai compris, c'est que si l'application est multi-thread, il faut s'assurer que le contexte créé est local au thread. Si l'application tourne deux threads et que les deux ont besoin d'OpenGL, chaque thread va créer son propre contexte GLX. Ce qui explique le premier pointeur. A la création d'un contexte, on verifiera si la variable est nulle. Si c'est le cas, nous créons un nouveau contexte.

Le contexte partagé partout est moins clair pour moi. Apparement un contexte GLX unique, obligatoirement inactif et lié à une fenêtre cachée, est créé au début de l'application (du moins la première fois qu'un contexte OpenGL est demandé) et détruit à la fin (lorsque nous n'avons plus besoin d'aucun contexte OpenGL). Mais à quoi sert ce partage ? Je vois plus loin dans les sources qu'il est envoyé lors de l'appel à glXCreateContext afin de "partager les display list". Parle-t-on bien des display list de la terminologie OpenGL ? Ça partage seulement ça ou aussi les programmes de shader, les texture objects, VBO, VAO, ... ?

Et enfin, le moins clair pour moi, là, c'est les contextes internes. Je n'arrive pas à comprendre leur utilisation. On a un contexte interne par thread et un ensemble de contextes internes globaux. Je suppose que le contexte interne local au thread est aussi présent dans l'ensemble ? Combien y a-t-il de contexte internes en tout ? Un par thread ?
Tout ce que je vois, c'est que lorsqu'on utilise setActive avec false pour désactiver un contexte, un contexte interne est activé à la place. Est-ce le seul but ?

Si quelqu'un peut m'éclairer sur tout ça; ce serait super

En attendant, je félicite Laurent pour le travail remarquable qu'il a fait sur sa bibliothèque

3

Système / Re : [SFML2]Communication avec mon Thread

« le: Avril 19, 2012, 08:45:58 am »

Ah vi, je l'avais sautée celle là.
Merci

4

Système / [RESOLU][SFML2]Communication avec mon Thread

« le: Avril 19, 2012, 12:43:09 am »

Bonsoir,

J'avoue ne pas du tout être habitué au développement multi-thread, aussi je ne comprends pas beaucoup comment arriver à mes fins.
Le code ci dessous lance un thread qui boucle, en attendant que le champ "valeur" passe à 0. Ceci était facilement faisable avec un héritage de sf::Thread dans l'ancienne version de SFML.
Mais maintenant le constructeur de sf::Thread prend en paramètre une copie de l'objet-foncteur. Je n'ai plus la main sur le champ "valeur" qu'il faut et je ne peux plus arrêter ma boucle.

class MaClasse
{
        public:
               
                // Constructeur
                MaClasse(int p) : valeur(p)     {}

                // Point d'entrée
                void operator()()
                {
                        while(valeur != 0)
                                std::cout << "P doit valoir 0 pour quitter" << std::endl;
                }

                // Champ interne
                int valeur;

};



int main(int argc, char* argv[])
{
        MaClasse vClasse = 10;
       
        sf::Thread vThread(vClasse);
        vThread.launch();

        vClasse.valeur = 0;

        return 0;
}
 

Je me demande donc.. comment modifier les valeurs de l'objet MaClasse de mon thread depuis le main ?

A plus tard