L'association d'écrans haute densité et d'applications de bureau classiques a soulevé de nombreuses questions : pourquoi l'Explorateur Windows apparaît-il flou ? Comment activer le mode Hi-DPI sur les clients distants ? Quels paramètres ajuster sous Windows (réglage du DPI, mise à l'échelle et résolution sous Windows 11) , macOS ou Linux ? Que doivent faire les développeurs pour garantir la netteté de leurs applications tout en s'adaptant à différents écrans ? Ce texte rassemble toutes les informations nécessaires pour comprendre et résoudre ce problème, des aspects les plus pratiques aux plus techniques.
Si vous cherchez des solutions pour résoudre les problèmes de fenêtres floues, de menus minuscules sur un écran 4K ou pour forcer une mise à l'échelle correcte sur les écrans ultra-larges 2560x1080 (par exemple, comment sélectionner manuellement la résolution ), vous êtes au bon endroit. Outre des solutions pour les utilisateurs, vous découvrirez ce que signifie concrètement la prise en charge du DPI (par écran, v1 et v2), des astuces concernant les fichiers manifestes et la compatibilité, ainsi que des instructions précises pour la mise à jour des applications Win32, Windows Forms ou WPF.
Qu'est-ce que Hi-DPI et pourquoi certaines applications sont-elles floues ?
Les écrans modernes possèdent une densité de pixels (PPI) bien supérieure à celle d'il y a quelques années (passant des 96 PPI traditionnels à 300 PPI, voire plus). Lorsqu'une application ne peut s'adapter à cette augmentation, Windows agrandit son interface à l'aide d'une image bitmap, ce qui provoque un flou lors du redimensionnement. Windows 11 propose même des fonctionnalités comme la Super Résolution automatique pour tenter d'améliorer l'apparence.
Dans la terminologie Microsoft, une application peut être non compatible avec les différences de résolution (DPI), compatible avec le système ou compatible avec chaque moniteur. Chaque profil définit si le système redimensionne automatiquement l' application ou si celle-ci doit être redessinée avec le nouveau facteur d'échelle. Plus le niveau de compatibilité DPI est élevé, plus l'affichage sera net lors du déplacement de la fenêtre entre des moniteurs de résolutions différentes.
Le cas de l'Explorateur de fichiers et des applications système floues
De nombreux utilisateurs constatent que l' onglet Compatibilité est absent de C:\Windows\explorer.exe . L'Explorateur Windows étant un composant système nécessitant un traitement particulier, le panneau « Modifier le comportement de mise à l'échelle PPP » n'y figure pas. Si l'Explorateur Windows ou le Panneau de configuration apparaissent flous, le problème provient généralement de la mise à l'échelle système (voir comment modifier et ajuster la résolution d'écran ) de parties de l'interface non compatibles avec les résolutions PPP.
Pour résoudre les problèmes d'affichage flou des applications, Windows 10/11 propose des options telles que « Laisser Windows tenter de corriger les applications pour qu'elles ne soient plus floues » et la possibilité de modifier la mise à l'échelle application par application. Bien que l'Explorateur Windows ne dispose pas d'un onglet Compatibilité, ces fonctionnalités système peuvent améliorer le comportement général. Pour les autres applications, vous pouvez appliquer des modifications de mise à l'échelle spécifiques dans leurs propriétés.
Modes de détection DPI sous Windows
Dans l'écosystème Windows, la gestion de la mise à l'échelle par une application est clairement définie. Comprendre cette classification est essentiel pour diagnostiquer pourquoi une fenêtre apparaît nette sur un écran et floue sur un autre présentant un facteur d'échelle différent.
| Mode | À partir de | Comment le PPP voit les choses | Comportement lors du changement de DPI |
|---|---|---|---|
| Pas conscient | N / A | Toujours 96 PPP (100%) | Mise à l'échelle des bitmaps (flou) |
| Système conscient | windows Vista | Un seul DPI : celui du moniteur principal lors de la connexion | Il semble net uniquement à ce DPI ; si vous changez de moniteur/d'échelle, Windows agrandir l'image bitmap (flou) |
| Par moniteur (v1) | Windows 8.1 | DPI du moniteur sur lequel la fenêtre est principalement située | Le HWND de haut niveau reçoit WM_DPICHANGED; il n'y a pas de mise à l'échelle automatique des éléments de l'interface utilisateur |
| Par moniteur v2 | Fenêtres 10 1703 | DPI du moniteur actif par fenêtre | Les HWND de niveau supérieur et secondaires reçoivent une notification ; Windows met à l'échelle la zone non cliente, dialogues et thèmes à partir de comctl32 V6 automatiquement |
Dans la version 2 par moniteur, l'application n'est jamais mise à l'échelle par le système et doit redimensionner/redessiner son contenu après un événement WM_DPICHANGED. En contrepartie, Windows vous épargne le travail sur les éléments non clients (titre, barres de défilement), les boîtes de dialogue Win32 et certains contrôles avec thèmes.
Mettre à jour une application existante pour la rendre plus claire
L'étape minimale consiste à marquer le processus comme étant de type « par moniteur v2 » (manifeste ou API) et à déplacer la logique de mise en page hors de l'initialisation afin qu'elle s'exécute également lors d'un changement de DPI (WM_DPICHANGED). Parallèlement, il convient de revoir certaines hypothèses : cesser de mettre en cache indéfiniment les tailles de police et les valeurs dépendantes du DPI ; recalculer lors d'un changement d'échelle.
De nombreuses API Win32 n'exposent pas le contexte DPI et renvoient donc des valeurs relatives au DPI du système. Il est conseillé de remplacer les appels classiques par des variantes prenant en charge le DPI ; par exemple, utiliser GetSystemMetricsForDpi au lieu de GetSystemMetrics et appliquer des fonctions telles que EnableNonClientDpiScaling dans WM_NCCREATE.
Mode mixte : DPI par thread
Si votre application est volumineuse ou utilise plusieurs interfaces utilisateur tierces, vous pouvez procéder par étapes : mettez à jour la fenêtre principale en mode par moniteur et laissez les fenêtres secondaires, de niveau supérieur, dans leur mode d'origine. Pour cela, vous pouvez utiliser la méthode SetThreadDpiAwarenessContext , qui associe la prise en charge des DPI aux fenêtres créées lorsque ce contexte est actif.
N'oubliez pas que le mélange de modes accroît la complexité et que Windows interdit d'enfreindre certaines règles (par exemple, un arbre HWND ne peut pas mélanger différentes consciences entre parent et enfant). Tout écart par rapport à ces règles peut entraîner une réinitialisation du mode DPI du processus ou renvoyer des erreurs telles que ERROR_INVALID_STATE lors du changement de parent.
Tests essentiels et problèmes courants
Essayez de déplacer des fenêtres entre des écrans de résolutions différentes, de les lancer sur chaque écran, de modifier le facteur d'échelle à la volée, puis, après avoir changé d'écran principal, de vous déconnecter et de vous reconnecter pour détecter la mise en cache des résolutions/tailles. Ajoutez des suites de tests utilisant le Bureau à distance depuis des machines à résolution élevée/faible.
Problèmes typiques : non-utilisation du rectangle suggéré par WM_DPICHANGED ; virtualisation des valeurs lorsque le thread n’est pas dans le contexte DPI correct ; et API sans contexte DPI qui forcent le chargement manuel des ressources (par exemple, le remplacement de LoadIcon par LoadImage pour les tailles appropriées).
SSMS sur écrans 4K : manifeste externe et remplacement de la mise à l'échelle
SQL Server Management Studio (SSMS) s'est amélioré, mais la prise en charge des écrans haute résolution (DPI élevé) est restée longtemps partielle. Deux méthodes efficaces permettent d'y remédier : l'utilisation d'un manifeste externe et la modification de la mise à l'échelle dans les paramètres de compatibilité.
Manifeste externe : Créez la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide avec PreferExternalManifest=1 (DWORD). Enregistrez un fichier ssms.exe.manifest (UTF-8) dans le même répertoire que ssms.exe pour indiquer la prise en charge des résolutions DPI. Redémarrez l’ordinateur ; les icônes et le texte seront plus nets en UHD 3840×2160.
Modification du comportement de mise à l'échelle : Dans le raccourci SSMS, sous l'onglet Compatibilité, cochez « Modifier le comportement de mise à l'échelle pour les résolutions élevées » et choisissez « Application ». SSMS se comportera ainsi comme une application par moniteur, empêchant Windows de le redimensionner image par image lorsque la résolution change.
Pour vérifier la prise en charge DPI d'un processus, Process Explorer (Sysinternals) permet d'ajouter la colonne « Prise en charge DPI ». Vous verrez des états tels que « Inconnu » (toujours adapté au système), « Compatible avec le système » ou « Par moniteur ». Cette vérification est très utile pour anticiper le comportement d'une application donnée.
Coordonner la virtualisation et les API sans contexte DPI
Lorsqu'une application ou un thread s'exécute en mode non-système ou système, Windows peut virtualiser des valeurs (par exemple, la taille de l'écran) pour « simuler » une résolution de 96 ppp, ce qui perturbe les diagnostics. Assurez-vous que le thread fonctionne dans le contexte de résolution attendu lors de l'interrogation des métriques ou de la création de fenêtres, et rétablissez ce contexte après l'utilisation de SetThreadDpiAwarenessContext.
De nombreuses API classiques n'incluent pas HWND/DPI dans leur signature. Par exemple, pour charger des icônes, utilisez LoadImage plutôt que LoadIcon ; pour les métriques, utilisez GetSystemMetricsForDpi ; pour les applications non clientes, utilisez EnableNonClientDpiScaling. Ces ajustements permettent d'obtenir une interface utilisateur nette et précise, contrairement à une interface que le système redimensionne en fonction de la résolution d'une image bitmap.
Remarque importante : « hidpi.h » n’est pas Hi-DPI
Il existe une routine HID (Human Interface Device) appelée HidP_UsageListDifference dont l'en-tête est hidpi.h, ce qui peut prêter à confusion avec « Hi-DPI ». Cette API n'a rien à voir avec la mise à l'échelle de l'écran : elle sert à comparer les listes d'utilisation des périphériques HID (boutons/entrées) et à obtenir les différences entre les états précédents et actuels.
Sa signature renvoie HIDP_STATUS_SUCCESS et utilise les tampons PreviousUsageList et CurrentUsageList, stockant les utilisations disparues dans BreakUsageList et les utilisations apparues dans MakeUsageList. Un zéro dans une liste est interprété comme un délimiteur. De par son contexte, cette fonction est associée aux périphériques d'interface humaine (claviers, manettes de jeu), et non aux écrans haute résolution.
Diagnostic rapide avec Process Explorer
Si vous n'êtes pas certain du comportement d'une application en matière de mise à l'échelle, ajoutez la colonne « Compatibilité DPI » à Process Explorer. Vous verrez alors des états tels que « Inconnu » (le système effectue toujours la mise à l'échelle ), « Compatible avec le système » (l'application conserve la résolution DPI initiale et ne réagit pas aux changements) ou « Par moniteur ». Cette vérification est utile pour déterminer si vous avez besoin d'un fichier manifeste, d'une modification de la mise à l'échelle ou d'une refonte de la mise en page.
La maîtrise du Hi-DPI repose sur l'association des paramètres système (et des options de compatibilité) et des bonnes pratiques de développement. Grâce aux informations fournies ici, vous pouvez éliminer les interfaces floues, ajuster les écrans ultra-larges sous macOS aux véritables résolutions Hi-DPI, activer le mode haute densité dans Espaces de travail et, si vous êtes développeur, migrer votre application vers la version 2 par moniteur en suivant un plan précis : gérer l'événement WM_DPICHANGED, utiliser les métriques « pour le DPI » et exploiter le mode mixte lorsque nécessaire.
