Informations de l’adaptateur WebGPU et vie privée
Comprendre ce que représente un adaptateur WebGPU, quand il peut être indisponible et comment choisir un repli graphique sans profiler l’appareil.
Vous voulez la documentation structurée pour Empreinte ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
WebGPU permet à une application de demander un adaptateur graphique capable d’exécuter un appareil WebGPU. L’adaptateur décrit une capacité utile à une tâche, pas une identité. Sa disponibilité dépend du navigateur, du système, de la pile graphique, des règles et des ressources. Une application respectueuse de la vie privée ne demande que ce qui suffit à choisir une expérience et prévoit un repli clair en cas d’échec.
Ce que représente un adaptateur
La spécification WebGPU du W3C décrit l’adaptateur comme un objet représentant une implémentation graphique physique ou logicielle permettant de créer un appareil. L’application peut demander un adaptateur puis un appareil avec les limites et fonctions nécessaires. Le navigateur peut ne renvoyer aucun adaptateur, et une réponse positive ne garantit pas la création de l’appareil.
L’adaptateur n’est pas un inventaire du moteur de rendu. Commencez par un objectif visible, comme une scène interactive, un calcul ou un mode visuel réduit. La référence WebGPU de MDN documente l’API publique sans garantir une prise en charge universelle. La guide WebGL sur les capacités et la vie privée distingue les contrôles de capacité du suivi.
Disponibilité et limites d’autorisation
navigator.gpu n’est exposé que lorsque le navigateur implémente et autorise WebGPU dans le contexte courant. La demande d’adaptateur peut échouer ou ne rien renvoyer. La demande d’appareil peut ensuite échouer si des fonctions, limites ou ressources manquent. Ce sont des branches normales de compatibilité, pas des preuves sur une personne ou une machine particulière.
La spécification W3C définit le contrat de l’API ; la documentation du navigateur explique les restrictions propres aux versions. N’affirmez pas que WebGPU est disponible partout et ne promettez pas une invite ou des champs stables. Documentez la plage testée et gardez un parcours utile pour les contextes non pris en charge.
Décisions respectueuses de la vie privée
Utilisez la décision minimale qui choisit l’expérience. S’il suffit de savoir si l’appareil peut démarrer, conservez ce résultat et l’acceptation des fonctions requises. Ne retenez pas une description complète de l’adaptateur, ne combinez pas les données graphiques avec celles du compte ou du réseau et ne transformez pas les différences en identifiant persistant. Une décision de session suffit souvent ; une préférence de qualité mémorisée doit être un choix explicite de l’utilisateur.
Les diagnostics ont un but distinct. Si le support a besoin d’informations supplémentaires, expliquez la collecte, limitez l’accès et fixez une durée de conservation. Ne demandez pas par défaut un inventaire de l’adaptateur. Le guide de vie privée entre surfaces décrit l’impact de la combinaison de signaux.
Repli et récupération accessible
Gardez le contenu et les commandes essentielles hors de la surface graphique. Si l’adaptateur ou l’appareil échoue, proposez une scène réduite, une image, un tableau ou une autre représentation qui accomplit la même tâche. Conservez les filtres et les saisies, expliquez le changement et évitez une toile vide ou des tentatives infinies.
Testez le succès, l’absence d’adaptateur, le refus de l’appareil, une panne de ressources et une perte ultérieure du contexte. Le résultat attendu est une expérience utilisable, pas une description détaillée du matériel. Utilisez le HTML pour les noms, états, commandes clavier et informations équivalentes. Le guide du fingerprinting WebGPU traite le suivi ; cet article reste centré sur les décisions normales de capacité.
Planifier la demande selon le résultat
Définissez la tâche et le résultat visuel indispensable avant la demande.
Gardez navigation, compte et aide dans des contrôles HTML.
Utilisez des modes standard, réduit et statique.
Si une fonction manque, choisissez le mode documenté sans lire d’autres champs.
Garder les données temporairement
Le résultat de session suffit souvent.
Mémorisez un choix de qualité, pas les faits de l’adaptateur.
Un diagnostic peut noter l’étape et la version, jamais l’objet complet.
La capacité graphique ne prouve aucune donnée sensible.
Traiter les échecs comme un produit
Testez l’absence de WebGPU, l’adaptateur vide et le refus de l’appareil.
Séparez les pannes réseau des pannes graphiques.
Conservez filtres, état et commandes clavier dans le repli.
Notez la plage testée avec W3C et MDN sans promesse universelle.
Préparez la structure de la page avant la demande.
Le mode réduit doit accomplir la tâche principale.
Ne nommez pas le matériel pour expliquer un échec ordinaire.
Limitez le nombre de nouvelles tentatives.
Conservez l’état lors d’une perte de contexte.
Le résultat doit rester visible sans animation.
Examinez aussi le flux des bibliothèques tierces.
Donnez un but et une expiration aux caches.
Respectez les politiques administrées.
Expliquez séparément les erreurs réseau.
Supprimez les champs de journal inutiles.
Vérifiez les sources publiques avant publication.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.