ADR-018 — Modèle d’imagerie d’Air : vectoriel pour le mode graphique, cellulaire pour le mode console

Statut : draft, en attente de revue BDFL. À intégrer au registre des ADRs après validation.

Décision

Air adopte deux modèles d’imagerie distincts, chacun natif à sa cible :

• Mode graphique (couche 3 air-wm + couche 4 air-ui-render-gpu) : modèle d’imagerie vectoriel inspiré de Quartz 2D / Display PDF. Primitives : paths, fills, strokes, transformations affines, blend modes, transparence composée selon des règles explicites, espaces colorimétriques gérés. Vello est retenu comme moteur de rendu candidat, en cohérence avec ADR-009.

• Mode console (couche 3 air-console + couche 4 air-ui-render-tui) : modèle d’imagerie cellulaire natif. Primitives : cellules indexées par (colonne, ligne), glyphes stylés, attributs cellulaires, dirty regions. Aucun modèle vectoriel imposé au-dessus.

Aucune unification des deux modèles n’est tentée à ce niveau. L’unification se fait exclusivement au-dessus, dans l’API déclarative de composition de vues (cf. ADR-009 et ADR-009-bis).

Justification

Le modèle vectoriel pour le mode graphique apporte cinq bénéfices structurants, dans l’ordre où ils pèsent :

Indépendance de résolution. Le rendu vectoriel s’adapte sans aliasing à n’importe quel DPI, HiDPI, ou combinaison d’écrans hétérogènes. Critique pour le principe 4 de la Charte (longévité du matériel) : un écran de 2015 et un de 2025 partagent la même API et la même fidélité.

Accessibilité par agrandissement. L’agrandisseur intégré prévu par ADR-017 peut re-rendre à n’importe quelle échelle sans perte. Avec un buffer raster, on serait condamné à l’interpolation et donc à la dégradation. Le modèle vectoriel rend l’agrandissement parfait par construction.

Capture vectorielle native. Une capture d’écran ou de fenêtre peut être produite directement en PDF vectoriel, et non en raster. Utilisable pour documentation, archivage, partage avec des outils de traitement de texte, comparaison de versions. C’est une propriété émergente du choix du modèle d’imagerie, pas une feature à ajouter.

Impression native. Pas de pipeline d’export séparée : on imprime la même scène qu’on affiche, sans conversion intermédiaire. Cohérent avec l’approche macOS historique.

Analyse par agents IA. Les agents IA actuels analysent les UIs par OCR sur captures raster, avec une qualité variable (erreurs de lecture, perte de structure). Une capture vectorielle leur donne le texte exact, les positions exactes, les couleurs précises. Cette utilité est complémentaire de l’arbre sémantique fourni par ADR-002 + ADR-017 : l’arbre sémantique reste le canal principal pour qu’un agent comprenne ce que fait l’UI et puisse agir dessus ; la capture vectorielle est un complément précieux pour le raisonnement visuel (revue de design, debug visuel, comparaison de captures).

Le modèle cellulaire pour le mode console est conservé parce que le rendu console est intrinsèquement discret : cellules adressables, glyphes par cellule, dimensions variables selon contexte d’exécution (DRM/KMS sur air-console, ou simple grille colonnes × lignes sur terminal tiers selon ADR-008). Forcer un modèle vectoriel par-dessus serait sur-ingénierer sans bénéfice — la capture/sérialisation en mode console se fait nativement comme un dump structuré de la grille, plus efficient et portable qu’un PDF pour ce cas.

Conséquences

L’API publique du framework de vues (couche 4) ne parle ni en commandes vectorielles ni en commandes cellulaires : elle parle un vocabulaire de composition déclarative et de widgets sémantiques. Le choix du modèle d’imagerie est une décision interne aux renderers de la couche 4 et à la pipeline de rendu de la couche 3. Cette frontière est durcie par ADR-009 (révision intégrant l’amendement déclaratif).

Le pont entre le scene-graph déclaratif et le moteur de rendu vectoriel est interne à air-ui-render-gpu. Le pont entre le scene-graph déclaratif et le moteur cellulaire est interne à air-ui-render-tui. Ces deux ponts sont des composants critiques de la couche 4, à concevoir avec le même niveau de soin que le runtime de composition lui-même.

La capture vectorielle au niveau du compositeur air-wm suppose que le compositeur ait accès à la représentation vectorielle des fenêtres qu’il compose. C’est trivial pour les apps natives Air dont le rendu se fait en local puis transmet un buffer Wayland — la capture vectorielle nécessite alors une coopération entre compositeur et app (le compositeur demande à l’app de re-rendre vers PDF). Pour les apps Wayland tierces qui n’envoient que des buffers raster, la capture est dégradée en raster. C’est acceptable et documenté.

Non-décisions explicites

air-console ne reçoit pas de modèle vectoriel. Toute proposition future de « vectorialiser » le mode console doit faire l’objet d’un nouvel ADR amendant celui-ci.

Le format exact de capture vectorielle (PDF strict, PDF tagged, PostScript, SVG, format Air interne) n’est pas tranché. Il fera l’objet d’une décision lors de l’implémentation de la fonctionnalité de capture, probablement en phase post-air-base 1.0. Le PDF tagged (avec marqueurs accessibilité) est le candidat naturel parce qu’il préserve une partie de la structure sémantique.

Questions ouvertes renvoyées à des ADRs futurs

Rendu côté client vs scene-graph transporté. Deux options pour faire profiter air-wm du modèle vectoriel : (i) les apps rendent en local et envoient un buffer Wayland standard — air-wm ne voit que des pixels, sauf coopération explicite pour la capture ; (ii) les apps natives Air envoient leur scene-graph au compositeur via un protocole privé AirCom, et air-wm rend lui-même — capture vectorielle universelle de toutes les apps natives, mais surface du compositeur élargie et fossé avec les apps Wayland tierces. À trancher dans l’ADR « Protocole privé AirCom entre air-wm et apps natives » déjà identifié dans le README.

Politique d’accès des agents IA à la capture vectorielle et à l’arbre sémantique. Dans la continuité de la capability air.accessibility.observer (ADR-017), il faudra définir comment un agent IA obtient le consentement de l’utilisateur pour accéder à ces canaux. À traiter dans un ADR de politique d’accès aux APIs d’observation.

Références croisées

• ADR-001 (IPC AirCom) — le transport éventuel d’un scene-graph vers le compositeur passerait par AirCom.
• ADR-002 (modèle d’objet C-ABI) — porte les types primitifs (Path, Color, AffineTransform) du modèle vectoriel, observables et bindables.
• ADR-003 (compositeur Wayland) — air-wm est le compositeur qui bénéficie du modèle vectoriel.
• ADR-007 (air-console) — conserve son modèle cellulaire, non remis en cause.
• ADR-008 (air-tui trois backends) — la capability API mentionnée ici permet déjà aux apps de connaître leur contexte d’exécution ; étendue ici à la déclaration de fonctionnalités vectorielles indisponibles en console.
• ADR-009 (framework de vues : air-view / air-ui / air-tui) — Vello était déjà candidat ; ADR-018 acte le choix architectural sous-jacent. ADR-018 vit sous l’API déclarative d’ADR-009.
• ADR-017 (accessibilité) — la capture vectorielle complète l’arbre sémantique ; l’agrandisseur intégré bénéficie directement du modèle vectoriel.

Licence du document : MPL 2.0 Statut : draft, en attente de revue BDFL.