Dépassez le bureau en gardant les yeux ouverts
Ailloli UI sépare déjà sa scène retenue de l'hôte et du moteur de rendu. Cela ouvre des portes passionnantes, mais beta.2 ne rend pas chaque porte également prête.
Résultat : vous saurez quel chemin est utilisé par défaut, quelles crates sont séparées, ce que prouve une vérification des entrées sans matériel et ce qui exige encore un vrai système XR.
01
Commencez par le chemin livré avec la façade
La feature winit par défaut apporte l'hôte natif et le moteur WGPU principal. Les applications de bureau ordinaires n'ont besoin d'aucune dépendance Vulkan ou OpenXR.
Votre application
Widgets, State, actions et fenêtres construits avec ailloli_ui.
Scène portable
Le runtime retenu produit des couches et des valeurs DrawCmd.
Winit + WGPU
L'hôte de bureau principal crée les surfaces et rend la scène.
02
Lisez les étiquettes avant de choisir un chemin
Disponible signifie que la source et le contrat public existent. Expérimental signifie que l'API peut évoluer rapidement et demande un travail d'intégration au-delà de la façade.
Carte des capacités de beta.2
Cinq chemins, chacun avec un niveau de maturité différent.
- Principal
Bureau winit + WGPU
Chemin par défaut de la façade pour les fenêtres de bureau natives et le rendu GPU.
- Expérimental
Moteur Vulkan
Crate séparée orientée hôte. Elle enregistre une Scene retenue dans des cibles Vulkan appartenant à l'hôte.
- Intégration partielle
Adaptateur d'entrées XR
Le mappage de pointeur indépendant de l'hôte est disponible sans démarrer de session OpenXR.
- Expérimental
Chemin runtime OpenXR
Chemin hôte séparé derrière une feature, qui exige une validation réelle du loader, du runtime, du GPU et du matériel.
- Expérimental
Superposition native de bureau
La feature optionnelle native_overlay crée une superposition qui ne prend pas le focus avec les backends Linux X11 ou Wayland layer-shell. Les autres plateformes ne sont pas prises en charge en beta.2.
La publication de beta.2 dans le registre est encore en cours. Confirmez que la version exacte de chaque crate est listée avant d'utiliser un manifeste fondé uniquement sur le registre.
03
Vulkan est un moteur de rendu, pas un interrupteur d'application
ailloli_ui_render_vulkan consomme les données Scene et DrawCmd, puis enregistre des commandes Vulkan dans une cible fournie par un hôte spécialisé.
Cycle de vie possédé par l'hôte
L'hôte possède le périphérique Vulkan, la file, le pool de commandes, l'image cible, le rythme des images rendues et la présentation.
Crate séparée
La façade ailloli_ui ne propose aucune feature Vulkan en beta.2. Ajoutez directement la crate de rendu pour une intégration personnalisée.
Shaders à la compilation
La crate compile le GLSL en SPIR-V avec shaderc pendant le build. Un cargo check réussi ne prouve ni le pilote ni le chemin de présentation.
La parité de rendu reste incomplète
Les commandes RingProgress et Polyline sont ignorées en beta.2, les images non prises en charge sont comptées comme ignorées et le moteur attend sa file après l'envoi. Mesurez la charge réelle avant de vous appuyer dessus.
04
OpenXR combine des adaptateurs et un runtime facultatif
ailloli_ui_openxr est également séparée de la façade. Son mappage d'entrées indépendant de l'hôte transforme des échantillons de pointeur XR en événements Ailloli UI ordinaires.
Adaptateur d'entrées
Les identifiants de pointeur, impacts, transitions de gâchette et deltas de défilement peuvent être mappés sans créer de session OpenXR.
Feature openxr
La feature openxr active le chemin hôte OpenXR chargé avec Vulkan. Elle exige un loader, un runtime, un périphérique compatible et un vrai cycle de vie hôte.
Feature smoke_ui
Elle ajoute la scène de smoke test intégrée utilisée par les hôtes d'exemple. C'est une aide à la validation, pas un framework d'application destiné à l'utilisateur final.
05
Une vérification sûre des entrées sans matériel
Ce programme traduit deux trames contenant un impact pour le même pointeur XR, d'abord relâché puis pressé. Il prouve que l'adaptateur d'entrée public peut produire une transition, mais pas qu'un runtime XR peut présenter une image rendue.
Déclarez explicitement la frontière
Le probe commence par l'adaptateur d'entrées sans matériel. Des features facultatives exposent des probes de types Vulkan et du runtime OpenXR.
[package]
name = "experimental-hosts"
version = "0.1.0"
edition = "2021"
rust-version = "1.88"
publish = false
[features]
default = []
vulkan-probe = ["dep:ailloli_ui_render_vulkan"]
openxr-runtime = ["ailloli_ui_openxr/openxr"]
[dependencies]
ailloli_ui_core = "=0.1.0-beta.2"
ailloli_ui_openxr = { version = "=0.1.0-beta.2", default-features = false }
ailloli_ui_render_vulkan = { version = "=0.1.0-beta.2", optional = true }use ailloli_ui_core::event::Modifiers;
use ailloli_ui_core::Point;
use ailloli_ui_openxr::{
map_samples_to_openxr_input_events, OpenXrInputMapper, OpenXrPointerFrame, OpenXrPointerHit,
OpenXrPointerSample, PointHit,
};
fn main() {
let hit = OpenXrPointerHit::Hit(PointHit::new(Point::new(120.0, 80.0), None));
let released = OpenXrPointerFrame::new(vec![OpenXrPointerSample::new(1, hit, false)]);
let pressed = OpenXrPointerFrame::new(vec![OpenXrPointerSample::new(1, hit, true)]);
let mut mapper = OpenXrInputMapper::new();
let _hover_events =
map_samples_to_openxr_input_events(&mut mapper, &released, Modifiers::default());
let press_events =
map_samples_to_openxr_input_events(&mut mapper, &pressed, Modifiers::default());
assert!(!press_events.is_empty());
#[cfg(feature = "vulkan-probe")]
let _vulkan_options = ailloli_ui_render_vulkan::VulkanRendererOptions::default();
#[cfg(feature = "openxr-runtime")]
let _openxr_options = ailloli_ui_openxr::OpenXrRuntimeOptions::default();
}L'adaptateur d'entrée par défaut, la vérification des types Vulkan et la feature du runtime OpenXR passent tous cargo +1.88.0 check avec la source beta.2.
06
Ce qu'une compilation réussie ne peut pas prouver
Un logiciel immersif traverse les frontières du matériel, du pilote, du loader, du runtime, du graphisme et des interactions. Validez chacune sur le système cible.
Loader et runtime
Un loader OpenXR et un runtime actif doivent exposer les extensions requises.
Compatibilité GPU
Le périphérique physique Vulkan choisi et ses files doivent correspondre aux exigences du runtime XR.
Interactions réelles
Les contrôleurs, mains, rayons, focus, transitions de gâchette et l'échelle du panneau demandent des essais sur le matériel.
Comportement des frames
Vérifiez le rythme des frames, la synchronisation, les swapchains, la netteté du texte et la récupération après erreur sous la charge réelle.
Vous avez atteint la frontière
Vous pouvez maintenant construire une application de bureau agréable, comprendre son runtime retenu, l'inspecter et évaluer des hôtes expérimentaux sans confondre la présence du code source avec une préparation à la production.
À vous de jouer
Exercice : ajoutez un geste de défilement à la sonde
Prolongez la sonde de pointeur sans matériel avec un type d'entrée supplémentaire.
- 1Ajoutez with_scroll(0.0, 12.0) à l'échantillon de pointeur relâché.
- 2Cherchez un événement de défilement dans le premier lot tout en conservant la transition de pression dans le second.
Gardez le point touché et l'identité du pointeur inchangés. Un déplacement non nul en pixels logiques suffit à produire un défilement.
Le premier lot contient un défilement, le second contient toujours une transition de pression et aucun runtime XR ne démarre.