Si vous ouvrez l'Explorateur de fichiers et que tout semble flou et que vous ne trouvez pas l'onglet de compatibilité dans l'exécutable du système, vous n'êtes pas seul. La mise à l'échelle Hi-DPI (DPI) dans Windows combine des composants modernes et hérités, et cela conduit à des résultats étranges : texte flou, commandes disproportionnées et comportement incohérent entre les applications.
La situation s’aggrave lorsque vous changez de moniteur ou modifiez le facteur d’échelle. Les applications UWP fonctionnent généralement bien, mais les applications Win32 nécessitent une certaine attention.Ici, nous combinons la théorie officielle de Microsoft avec des cas réels (Explorer, Office, SSMS, Chrome, Adobe) et du code pour vous aider à comprendre ce qui se passe et comment réagir.
Pourquoi n'y a-t-il pas d'onglet de compatibilité pour explorer.exe ?
Il est normal que l'onglet de compatibilité n'apparaisse pas dans C:/Windows/explorer.exe. L'Explorateur fait partie du shell Windows et est protégé, ses paramètres ne sont donc pas gérés comme ceux de n'importe quelle autre application. Par conséquent, vous ne pouvez pas forcer, par exemple, un remplacement de DPI depuis ses propriétés.
Si l'Explorateur et le Panneau de configuration semblent flous, la cause n'est pas un seul commutateur caché. Le problème réside dans la façon dont Windows fait évoluer l’interface héritée En cas de modification de la résolution ou d'utilisation d'un écran haute densité, le contrôle de ce problème repose sur la compréhension des modes de reconnaissance de la résolution et des options système permettant de corriger les applications floues.
PPP et facteur d'échelle : les bases à comprendre
À mesure que la densité des pixels augmente, Les panneaux modernes sont passés de 96 DPI à des chiffres proches de 300 DPI ou plusPour rendre tout lisible, Windows applique un facteur d’échelle et les applications doivent y réagir.
De nombreuses bases de code Win32 étaient basées sur une hypothèse qui n'est plus vraie : Le PPP a été fixé tout au long de la vie du processusAujourd'hui, avec les ordinateurs portables qui se connectent et se déplacent entre les écrans 1080p et 4K, le DPI change à la volée, parfois plusieurs fois au cours d'une seule session.
Scénarios typiques où le DPI ou le facteur d'échelle change : déplacer les fenêtres entre les moniteurs avec différentes échelles, connectez/déconnectez votre ordinateur portable, lancez le Bureau à distance depuis/vers des ordinateurs avec différents DPI ou appuyez sur le contrôle de mise à l'échelle dans les paramètres lorsque les applications sont ouvertes.
Modes de détection DPI sous Windows
Les applications de bureau doivent indiquer à Windows si elles savent comment gérer la mise à l’échelle. Si ce n’est pas le cas, le système suppose 96 DPI et étire la bitmap., qui semble flou. Voici les principaux modes :
PPP inconscientL'application affiche une résolution de 96 ppp (100 %). Sur les écrans plus grands, Windows agrandit l'image bitmap à la taille physique attendue, ce qui rend l'interface floue.
Système conscient- L'application prend le DPI du moniteur principal lors de la connexion et dimensionne son interface utilisateur en conséquence. Si vous le déplacez vers un autre moniteur avec un DPI différent, Windows l'étire et il devient flou.Il n'a l'air net qu'au DPI pour lequel il a été initialisé.
Prise en compte par moniteur (Per-monitor, V1):Introduit dans Windows 8.1. Les fenêtres de niveau supérieur reçoivent une notification de changement DPIWindows ne redimensionne pas l'image bitmap et l'application voit des pixels physiques sur chaque écran. C'est fonctionnel, mais limité.
Par moniteur v2: Recommandé depuis Windows 10 1703. Fournit des améliorations clés : notifications aux HWND de niveau supérieur et secondaires, Windows met automatiquement à l'échelle la zone non cliente (titre, barres de défilement), Boîtes de dialogue CreateDialog et ressources thématiques (comctl32 V6) au DPI approprié. L'application voit les pixels bruts et Windows ne les redimensionne jamais.
UWP vs Win32 : pourquoi certaines choses sont belles et d'autres non
Si vous créez une application à partir de zéro et optez pour UWP, le framework Redessine automatiquement en fonction du DPI du moniteurIl n'y a rien d'autre à faire. Cependant, les technologies précédentes (Win32 pur, Windows Forms, WPF, GDI, MFC, etc.) ne sont pas évolutives d'elles-mêmes ; il faut le programmer ou ils apparaîtront flous, trop petits ou disproportionnés.
Cela se remarque dans les détails quotidiens de l'interface utilisateur classique : lorsque le système est réglé à 200 % la barre de défilement peut devenir plus épaisse et certains boutons peuvent rétrécir, avec des courbes et des bords étranges. Ce type de défaut affecte l'Explorateur et d'autres parties du shell Win32. non à l'UWP.
Quels frameworks sont les plus évolutifs (et lesquels ne le sont pas)
Selon Microsoft, la prise en charge des moniteurs varie selon la technologie. UWP bénéficie d'un support complet et le framework lui-même gère la mise à l'échelle. Win32 avec Common Controls V6 (comctl32.dll) en 1703 inclut des notifications à tous les HWND, Ressources avec des thèmes qui se redessinent vers le PPP correct et des dialogues qui s'adaptent à l'échelle.
Windows Forms a un mise à l'échelle automatique limitée du moniteur pour certains contrôles, alors que WPF natif évolue bien si vous restez dans WPF, la coexistence avec d'autres frameworks hébergés ne s'adapte pas automatiquement. GDI, GDI+ et MFC ne fournissent pas de support par eux-mêmes : la logique doit être implémentée par l'application.
Mettez à niveau votre application de bureau vers Per-Monitor (V2)
L’objectif minimum est que, à chaque changement de DPI, des parties importantes de l'interface utilisateur sont redimensionnéesSi votre application est actuellement compatible avec le système, Windows l'étirera et la rendra floue lors de sa mise à l'échelle. Pour éviter cela, convertissez-la en Per-Monitor V2 et redessinez-la à la volée.
Directives pratiques pour la migration : étapes clés pour éviter les étirements
- Déclare Per-Monitor V2 dans le manifeste ou utilisez l'API appropriée, en fonction de votre framework.
- Extraire la logique de mise en page depuis le démarrage et les transformer en routines réutilisables que vous appelez également sur WM_DPICHANGED.
- Réévaluer les données sensibles au PPP (polices, tailles, métriques) à chaque changement de DPI ; ne les mettez pas en cache.
- Recharger ou remasteriser les bitmaps à la nouvelle échelle ou, si cela n'est pas possible, accepte la mise à l'échelle bitmap pour ces ressources.
- Remplace les API non reconnues par variantes DPI : par exemple, GetSystemMetrics → GetSystemMetricsForDpi.
- Tester dans des environnements à plusieurs niveaux de PPP (moniteurs multiples, RDP, mise à l'échelle à chaud).
- Pour Windows, vous ne pouvez pas encore mettre à jour, utilise une mise à l'échelle mixte avec reconnaissance de thread.
Exemple Win32 simplifié. Cas naïf (suppose 96 DPI) qui crée un bouton et qui a une mauvaise apparence à un DPI élevé :
case WM_CREATE: { // Add a button
HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,
50, 50, 100, 50, hWnd, (HMENU)NULL, NULL, NULL);
}Version adaptée : met à l'échelle la position et la taille avec GetDpiForWindow et répond à WM_DPICHANGED:
#define INITIALX_96DPI 50
#define INITIALY_96DPI 50
#define INITIALWIDTH_96DPI 100
#define INITIALHEIGHT_96DPI 50
void UpdateButtonLayoutForDpi(HWND hWnd) {
int iDpi = GetDpiForWindow(hWnd);
int dpiScaledX = MulDiv(INITIALX_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
int dpiScaledY = MulDiv(INITIALY_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
int dpiScaledWidth = MulDiv(INITIALWIDTH_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
int dpiScaledHeight = MulDiv(INITIALHEIGHT_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
SetWindowPos(hWnd, hWnd, dpiScaledX, dpiScaledY, dpiScaledWidth, dpiScaledHeight,
SWP_NOZORDER | SWP_NOACTIVATE);
}
...
case WM_CREATE: {
HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,
0, 0, 0, 0, hWnd, (HMENU)NULL, NULL, NULL);
if (hWndChild != NULL) { UpdateButtonLayoutForDpi(hWndChild); }
} break;
case WM_DPICHANGED: {
HWND hWndButton = FindWindowEx(hWnd, NULL, NULL, NULL);
if (hWndButton != NULL) { UpdateButtonLayoutForDpi(hWndButton); }
} break;Mise à l'échelle mixte et prise en compte des threads
Mettre à jour une interface utilisateur entière et volumineuse en une seule fois peut s'avérer irréaliste. C'est là que mode mixte (DPI par thread):Vous pouvez laisser certaines fenêtres de niveau supérieur dans leur état d'origine, tout en modernisant le reste.
À partir de Windows 10 1607, reconnaissance DPI peut être défini par fenêtre de niveau supérieurLes fenêtres enfants doivent hériter du mode de leur parent. Utilisez SetThreadDpiAwarenessContext. avant de créer la fenêtre pour l'associer à au mode souhaité et le restaurer ensuite.
Modèle C++ Pour verrouiller le contexte DPI du thread pendant la création :
class DpiAwarenessContextBlock {
public:
DpiAwarenessContextBlock(DPI_AWARENESS_CONTEXT dpiContext) noexcept {
m_contextReversalType = SetThreadDpiAwarenessContext(dpiContext);
}
~DpiAwarenessContextBlock() {
SetThreadDpiAwarenessContext(m_contextReversalType);
}
private:
DPI_AWARENESS_CONTEXT m_contextReversalType;
};Modèle géré équivalent (C#) pour la commutation et la restauration du contexte dans les blocs : utile dans les solutions avec plusieurs fenêtres.
class DPIContextBlock : IDisposable {
private DPI_AWARENESS_CONTEXT resetContext;
public DPIContextBlock(DPI_AWARENESS_CONTEXT contextSwitchTo) {
resetContext = SetThreadDpiAwarenessContext(contextSwitchTo);
}
public void Dispose() { SetThreadDpiAwarenessContext(resetContext); }
}Tests à ne pas manquer et erreurs typiques
Pour valider que votre application répond bien, déplacez-la entre des écrans à différentes échelles, lancez-le directement dans l'un ou l'autre, modifiez le facteur d'échelle pendant que l'application est en cours d'exécution et modifiez l'écran d'accueil, déconnectez-vous et réessayez.
Erreurs courantes :
- Ignorer le rectangle suggéré dans WM_DPICHANGED:Utilisez ceci pour redimensionner et éviter les boucles DPI et les sauts de curseur.
- Virtualisation mal documentéeSi vous appelez des API depuis un thread non pris en charge, Windows peut virtualiser les valeurs. Modifiez le contexte avec SetThreadDpiAwarenessContext et n'oubliez pas de le restaurer.
- API sans contexte PPP: Pour les icônes, les tailles, les métriques… utilisez des variantes comme LoadImage au lieu de LoadIcon ou GetSystemMetricsForDpi au lieu de GetSystemMetrics.
- Réinitialisation forcée de la reconnaissance du processusLes objets parents et enfants avec des modes DPI différents ne peuvent pas coexister dans la même arborescence HWND. Des opérations comme CreateWindow/SetParent avec des modes incompatibles peuvent forcer une réinitialisation ou échouer.
Bureau : à quoi ça sert et comment l'intégrer de manière transparente
Office 2016 et versions ultérieures sont mis à jour lorsque l'échelle change, mais les solutions d'évolutivité doivent être alignées pour un affichage correct. Si le réglage DPI vous affecte, vous verrez des fenêtres mal positionnées. contrôles hors site et des polices ou des images avec des tailles incorrectes.
Modes pertinents dans Office :
- Ignorant: toujours 96 DPI ; tout est étiré.
- Système conscient:Le DPI du moniteur principal est pris au démarrage ; lors des modifications ultérieures, Windows s'étire.
- Par moniteur: le niveau supérieur reçoit les notifications et se redessine. En v2, les filles les reçoivent également, mais Office n'utilise pas PMv2.
Contexte du thread : le thread Office principal est placé dans Par moniteur. Si vous créez des threads supplémentaires, Office les force à utiliser le mode par moniteurSi vous attendez un contexte différent, modifiez-le avec SetThreadDpiAwarenessContext. Dans les rappels Office, le contexte est pris en compte dans la mesure où il est conscient du système; ajustez-le à votre fenêtre.
Niveau supérieur vs. enfants : vos fenêtres de niveau supérieur peuvent être dans n’importe quel mode que vous choisissez et recevoir des notificationsLes fichiers secondaires doivent respecter la reconnaissance du fichier principal. Sous Windows 1709, les fichiers filles étaient gérés par moniteur ; depuis Windows 1803, Office peut le faire. utiliser le mode mixte pour améliorer la compatibilité (même si cela peut paraître flou en raison de l'étirement).
Paramètres utiles pour les utilisateurs : Dans Office, activez le mode de compatibilité d'affichage Forcer la reconnaissance du système (tout étiré, possiblement flou, mais cohérent). Sous Windows 10 1803+, l'option système Corriger les applications floues Cela aide également si votre solution n’est pas bien représentée.
Types d'extensibilité et nuances :
- VSTOLes fenêtres enfants doivent correspondre à la reconnaissance du parent (utilisez GetWindowDpiAwarenessContext). Les fenêtres de niveau supérieur peuvent être configurées dans n'importe quel mode. Vous pouvez implémenter un formulaire qui réagit à WM_DPICHANGED et contrôles d'échelle et sources dans OnDpiChangedEvent.
- Plugins COM: Pour les fenêtres de niveau supérieur, créez un bloc de contexte DPI avant de créer la fenêtre et gérez WM_DPICHANGED.
- ActiveX fenêtré: réagir à WM_SIZE ; Vous pouvez vérifier GetDpiForWindow et recalculer les positions et les sources.
- ActiveX sans fenêtre:En mode conception, le conteneur peut renvoyer 0 dans hDC et il n'y a pas de PPP fiable ; en exécution, Utilisez le HWND que le Bureau vous renvoie pour consulter le PPP et l'échelle.
- OLE:Il existe des restrictions dans les scénarios mixtes ; les versions récentes d'Office permettent l'activation locale avec des conditions basées sur le contexte DPI et l'option d'apparence/compatibilité choisie par l'utilisateur.
- Compléments Web:exécuter dans un contrôle de navigateur ; appliquer les mêmes techniques réactives que le Web.
SSMS sur écrans 4K : manifeste externe et alternatives
Sur les ordinateurs UHD, il est courant que SQL Server Management Studio apparaisse flou dans les anciennes versions. Un problème classique était activer les manifestes externes avec la clé de registre PreferExternalManifest et placez un fichier ssms.exe.manifest dans le dossier d'installation pour forcer la reconnaissance PPP.
Raccourci vers cette approche : créez la clé dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide avec le nom PreferExternalManifest (DWORD=1), enregistrez le manifeste dans le chemin de ssms.exe avec Codage UTF-8 et redémarrez. La prise en charge bêta Hi-DPI a été introduite dans SSMS 16.3 et les icônes ont été améliorées dans SSMS 17, mais les résultats ont varié selon la version et la configuration.
Un autre outil utile est Process Explorer (Sysinternals) pour ajouter la colonne DPI Aware et vérifier si un processus est non sensible, sensible au système ou par moniteur. Vous pouvez ainsi vérifier si votre ajustement a pris effet.
Alternative rapide sans manifestes : dans le Propriétés exécutablesDans l'onglet Compatibilité, cochez l'option « Remplacer le comportement de mise à l'échelle HAUTE DPI » et définissez « Mise à l'échelle effectuée par » sur « Application ». Cela force le mode Par moniteur et empêche Windows de s'étirer lorsque le DPI change. Dans de nombreux cas, il corrige le flou SSMS sans modifier le registre.
Références des colonnes de Process Explorer : Ignorant (le tout à 96 DPI, étiré par le système), Système conscient (utilise le DPI initial, puis s'étend en fonction des changements) et Par moniteur (redessiné en cas de changement). Chacun explique pourquoi une application apparaît nette ou floue selon le scénario.
Chrome et Adobe en Hi-DPI : à quoi s'attendre
Le rendu des polices de Chrome sur Windows pose problème depuis des années. Des correctifs ont été introduits dans les versions pour développeurs (comme Canary avec DirectWrite à l'époque) qui améliorait considérablement la netteté sur les écrans Hi-DPI, bien qu'au prix de pannes occasionnelles possibles ou d'une consommation CPU plus élevée dans les premières versions.
Dans la suite Adobe de la génération précédente, Photoshop pourrait afficher la petite interfaceAdobe a ajouté une option d'interface utilisateur à 200 % qui résout partiellement le problème dans les versions récentes ; avec les versions plus anciennes, vous deviez vivre avec de minuscules menus ou utiliser des raccourcis.
Dans InDesign et Illustrator, c'est le contraire qui s'est produit : taille correcte, mais floueLa solution consistait à désactiver la mise à l'échelle automatique dans Compatibilité (propriétés de raccourci) avec « Désactiver la mise à l'échelle de l'affichage lors de l'utilisation de paramètres DPI élevés », ce qui donnait une interface utilisateur plus petite mais plus nette.
Une autre bizarrerie de Photoshop : outils obsolètes ou triplésAjuster la taille des éléments à une valeur personnalisée (par exemple, 149 % ou 151 % au lieu de 150 %) sous « Agrandir ou réduire la taille du texte et des autres éléments » peut remettre votre site sur la bonne voie.
Si vous cherchez des alternatives, GIMP offre une option gratuite et puissante qui fonctionne bien dans les environnements à haute densité avec la bonne configuration.
Retour à Explorer : Ce que vous pouvez faire à partir du système
Même si vous ne pouvez pas toucher à la compatibilité dans explorer.exe, Windows 10 et les versions ultérieures sont dotés de deux lignes de vie pour l'expérience globale :
- Paramètres > Système > AffichageDéfinissez le facteur d'échelle recommandé et évitez les valeurs inhabituelles, sauf si elles répondent à des besoins spécifiques. Pour les ordinateurs qui changent fréquemment d'écran, il est préférable se déconnecter et se reconnecter après des changements majeurs.
- Paramètres > Système > Affichage > Paramètres de mise à l'échelle avancés: Activez « Laisser Windows essayer de réparer les applications afin qu’elles ne soient pas floues ». Cela aide avec les applications héritées lorsque vous changez d'écran ou d'échelle.
De plus, pour chaque application (à l'exception de l'Explorateur), vous pouvez ouvrir ses propriétés et utiliser « Remplacer le comportement de mise à l'échelle HAUTE DPI » pour choisir « Application », « Système » ou « Système (amélioré) » selon vos besoins. C'est une ressource efficace lorsqu'une application spécifique résiste et vous ne pouvez pas changer son code.
Compte tenu de tout ce qui précède, la situation générale est claire : Les UWP s'adaptent d'eux-mêmes, Win32 s'adapte bien aussi, et le reste doit être peaufiné.. L'explorateur et d'autres parties du shell entraînent des décisions historiques, mais l'écosystème propose des raccourcis et des API pour les contourner.
