Échange des tampons et effacement arrière en utilisant le système de fenêtrage (GLX)

Lors du basculement entre les mémoires tampon avant et arrière, le contenu de la mémoire tampon arrière devient indéfini. Je voudrais le définir en utilisant le “système de fenêtrage”, tel que GLX, EGL, WGL. Utiliser un rendu “natif” tel que OpenGL (glClear) est mon plan de sauvegarde, ne prenez pas la peine de le mentionner. La sauvegarde est due au fait que je ne veux pas me mêler des contextes de rendu natifs. Je vais m’en tenir à X / GLX pour cette question, mais si vous êtes enclin à décrire comment le faire dans d’autres environnements, continuez.

Dans la documentation Xlib ( http://www.x.org/docs/X11/xlib.pdf ), je trouve une opération, XClearWindow, pour effacer la fenêtre avec “pixel en arrière-plan” (nom génial d’ailleurs … pas).

  1. XClearWindow efface-t-il les tampons avant / arrière ou les deux? Je suppose que le tampon de retour a du sens, mais je ne peux pas le comprendre uniquement à partir de documents Xlib … Et si quelqu’un posait des questions sur le sortingple tampon, ce n’était pas moi!
  2. Est-il synchrone avec le rendu OpenGL ou dois-je me synchroniser moi-même en appelant par exemple glxWaitGL avant l’opération?
  3. La commande est-elle bloquante, c’est-à-dire s’arrête-t-elle jusqu’à la fin? Dépend de l’implémentation?

D’autres suggestions sur la manière d’effacer le tampon arrière après un échange utilisant le système de fenêtrage (GLX) sont appréciées.

À votre santé!

Lors du basculement entre les mémoires tampon avant et arrière, le contenu de la mémoire tampon arrière devient indéfini.

Oui, et c’est une bonne chose.

Je voudrais le définir en utilisant le “système de fenêtrage”, tel que GLX, EGL, WGL

Pourquoi? En dehors de cela, cela est tout aussi indéfini, car après un échange, l’arrière-plan ne produira rien de bon.

Au mieux, cela ne fera que dégrader les performances si le DDX OpenGL est conscient du XClearWindow à synchroniser. Dans le pire des cas, vous introduisez une condition de concurrence entre laquelle les résultats sont imprévisibles.

D’autres suggestions sur la manière d’effacer le tampon arrière après un échange utilisant le système de fenêtrage (GLX) sont appréciées.

Utilisez l’opération OpenGL appropriée: glClear(…) .

Après quelques recherches, j’ai peut-être trouvé une solution. Les documents semblent être en ordre mais je n’ai pas eu la chance de tester cela dans la pratique. Je vais mettre à jour la réponse avec le code une fois que quelque chose fonctionne.

XClearWindow efface-t-il les tampons avant / arrière ou les deux?

X n’a ​​pas la notion de double tampon. Chaque fois que vous interagissez avec X sur une fenêtre à double tampon, les deux tampons sont affectés. L’exception étant les opérations de lecture telles que XGetImage qui ne fonctionnent que sur le tampon avant.

Cependant, X est étendu avec un concept de double tampon via l’extension X Double Buffer Extension ou xdbe: http://www.x.org/releases/X11R7.6/doc/xextproto/dbe.html#dbeswapbuffers

xdbe fournit l’opération XdbeSwapBuffers similaire à glxSwapBuffers fournie par GLX. Il y a quelques différences importantes:

  • XdbeSwapBuffers ne gère aucune synchronisation avec une API cliente comme le fait glxSwapBuffers. L’utilisateur doit le faire manuellement. Heureusement, GLX fournit d’excellentes opérations de synchronisation ( glxWaitGL et glxWaitX ) qui ne glxWaitX pas l’exécution. Cela répond assez bien à ma deuxième question.
  • glxSwapBuffers effectue un vidage implicite ( glFlush ) pour le contexte actuel. XdbeSwapBuffers ne le fait pas. Quand vider ou non est une décision du concepteur d’applications.
  • XdbeSwapBuffers peut échanger plusieurs fenêtres en un seul appel.
  • Les comportements de XdbeSwapBuffers peuvent être différents lors du permutation: ‘Undefined’, ‘Background’, ‘Untouched’, ‘Copied’. Lisez le lien pour plus de détails.

Pour effacer après un échange sur une couleur prédéfinie, le comportement de changement de fond est la voie à suivre. Les éléments à clarifier peuvent être configurés via X et peuvent être un pixmap ou une couleur unique (pixel d’arrière-plan).

La commande est-elle bloquante, c’est-à-dire s’arrête-t-elle jusqu’à la fin? Dépend de l’implémentation?

Une application utilisant X doit fournir ses propres mécanismes de synchronisation dans de nombreuses situations. Cela indiquerait un modèle d’exécution asynchrone, mais la norme elle-même ne l’exige pas. Je vais avec “implémentation définie” avec une forte suggestion que la plupart des commandes pour la plupart des plates-formes sont exécutées de manière asynchrone.