Les états séparent la synchronisation, la visibilité, l’entrée, l’arrêt et la perte de session. Découvrez comment éviter les plantages et le gaspillage du GPU.
Réponse directe
OpenXR définit huit états de cycle de vie pour une session, de IDLE à EXITING. En SYNCHRONISÉ, l'application maintient la boucle d'image mais peut éviter un rendu lourd ; dans VISIBLE, il continue le rendu sans recevoir d'entrée XR ; dans FOCUSED, il reçoit également des informations. STOPPING appelle à fermer la boucle et xrEndSession, tandis que LOSS_PENDING appelle à détruire la session et, le cas échéant, à recréer les ressources système et graphiques.
Visible ne veut pas dire interactif
Une fenêtre contextuelle du système peut garder la scène visible et supprimer le focus. L'application doit suspendre les actions et masquer les avatars d'entrée inactifs sans supprimer la scène.
Synchronisé vous permet de sauvegarder le GPU
La boucle de trame continue, mais ShouldRender peut indiquer quelles couches n'ont pas besoin d'être envoyées. Dans cet état, le travail pénible rivalise pour les ressources sans avantage visuel.
L'ARRÊT est un ordre protocolaire
Ignorer l'événement et poursuivre le rendu peut bloquer les transitions. Quittez la boucle et terminez la session dans l'ordre attendu.
La perte de session nécessite une reconstruction contrôlée
La connexion d’affichage perdue rend les poignées inutilisables. Les ressources dépendantes du système doivent être détruites et recréées, sans promettre une reprise invisible.
Lecture Nexus
Modélisez chaque état explicitement, enregistrez les transitions et testez la veille, le mode modal, la suppression du casque, le changement d'application et la perte matérielle sur chaque environnement d'exécution pris en charge.
FAQ
Quand l’application reçoit-elle l’entrée XR ?
En état CONCENTRÉ ; VISIBLE affiche la scène, mais ne rend pas les actions éligibles à la saisie.
Dois-je arrêter la boucle d'image à SYNCHRONIZED ?
Non. Il doit rester synchronisé, évitant ainsi un travail fastidieux lorsque le rendu n'est pas nécessaire.
LOSS_PENDING peut-il être récupéré ?
L'application peut détruire la session, interroger un nouveau système et recréer des ressources si le contexte le permet.
Guides essentiels pour approfondir la décision
Cette analyse éditoriale a été réalisée par Nexus à partir des sources officielles ci-dessous, consultées le 24 octobre 2026. Le texte est original et interprète les implications pratiques pour les entreprises.
- Khronos — XrSessionState: états, sémantique, frame loop, focus, stop et recovery.
- Khronos — Spécification OpenXR: contrat normatif pour le runtime, les sessions, les événements et le rendu.
Date rapportée par source principale : OpenXR 1.1.65 consulté le 24 octobre 2026 ; analyse de modèles techniques.