en réalité, c'est un mécanisme assez mal expliqué sur internet et sur beaucoup de site il semblerait que deux threads ne puissent pas agir sur OpenGL en même temps.
Bien sur que si, tu peux faire tourner deux application OpenGL en même temps sans souci, le problème ici c'est le contexte, une même application peut faire tourner deux threads qui agiront chacun sur un contexte OpenGL différent (Partagés ou non), cependant le rendu vers une surface S est une opération qu'un seul thread peut effectuer (En tout cas de façon basique, il doit exister des solutions maintenant)
D'ailleurs ça n'aurait pas de réel intérêt d'agir sur un même contexte via deux threads en même temps car la majorité des fonctions de rendu ne font qu'ajouter une opération à la file d'attente de la carte graphique, file d'attente qui est traitée avec un appel à glFlush ou glFinish.
Avec la SFML (Et probablement toutes les applications OpenGL utilisant le double-buffering), le "flush" (traitement de la file d'attente) est fait juste avant l'échange de buffers (Sous windows : SwapBuffers), lors de l'appel à sf::Window::display, c'est ce qui prend le plus longtemps.
Une astuce employée par Qt, consiste à posséder un thread dit "de rendu", dont le seul but est d'effectuer l'échange de buffers (Et donc le flush), en activant d'abord le contexte approprié. Ça permet d'effectuer le rendu par la carte graphique tout en faisant faire des calculs au processeur (Physique, évènements, ...).
Ça n'a cependant d'intérêt qu'à partir du moment que les calculs du processeurs prennent plus de temps que l'activation du contexte (Donc inutile lorsqu'on ne gère que des évènements avec des calculs pas trop complexes, mais pratique dès qu'on est confronté à la physique).
Voila mon pavé
