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
