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).
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:
glxWaitGL
et glxWaitX
) qui ne glxWaitX
pas l’exécution. Cela répond assez bien à ma deuxième question. glFlush
) pour le contexte actuel. XdbeSwapBuffers ne le fait pas. Quand vider ou non est une décision du concepteur d’applications. 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.