Développement d’applications de bureau haute résolution sur Windows

Ce contenu est destiné aux développeurs qui cherchent à mettre à jour des applications de bureau pour gérer les changements de facteur d’échelle d’affichage (points par pouce ou PPP) dynamiquement, ce qui permet à leurs applications d’être nettes, peu importe le support d’affichage.

Pour commencer, si vous créez une application Windows à partir de zéro, il est vivement recommandé de créer une application de plateforme Windows universelle (UWP). Les applications UWP sont mises à l’échelle automatiquement et de manière dynamique pour chaque affichage sur lequel elles s’exécutent.

Les applications de bureau utilisant des technologies de programmation Windows plus anciennes (programmation Win32 brute, Windows Forms, Windows Presentation Framework (WPF), etc.) ne peuvent pas gérer automatiquement la mise à l’échelle PPP sans travail de développeur supplémentaire. Sans ce type de travail, les applications apparaissent floues ou mal dimensionnées dans de nombreux scénarios d’utilisation courants. Ce document fournit un contexte et des informations sur ce qui est impliqué dans la mise à jour d’une application de bureau pour s’afficher correctement.

Facteur d’échelle d’affichage & PPP

Comme la technologie d’affichage a progressé, les fabricants ont intégré un nombre croissant de pixels dans chaque unité d’espace physique sur leurs périphériques. Cela a entraîné des points par pouce (PPP) de panneaux d’affichage modernes beaucoup plus élevés qu’ils ne l’ont été par le passé. Dans le passé, la plupart des affichages avaient 96 pixels par pouce linéaire d’espace physique (96 PPP) ; en 2017, les affichages avec près de 300 PPP ou versions ultérieures sont facilement disponibles.

La plupart des infrastructures d’interface utilisateur de bureau héritées ont des hypothèses intégrées selon laquelle l’indicateur de points par pouce d’affichage ne changera pas pendant la durée de vie du processus. Cette hypothèse n’est plus vraie, avec des points par pouce d’affichage qui changent généralement plusieurs fois pendant toute la durée de vie d’un processus d’application. Voici quelques scénarios courants dans lesquels le facteur d’échelle d’affichage/PPP change :

• Configurations à plusieurs moniteurs où chaque affichage a un facteur d’échelle différent et l’application est déplacée d’un affichage à un autre (par exemple, un affichage 4K et un affichage 1080p)
• Ancrage et retrait de la station d’accueil d’un ordinateur portable haute résolution avec un affichage externe à faible PPP (ou vice versa)
• Connexion via le Bureau à distance à partir d’un ordinateur portable/tablette haute résolution à un appareil à faible PPP (ou inversement)
• Modification des paramètres de facteur d’affichage lors de l’exécution des applications

Dans ces scénarios, les applications UWP se redessinent automatiquement pour le nouveau PPP. Par défaut, et sans travail de développeur supplémentaire, les applications de bureau ne le font pas. Les applications de bureau qui ne font pas ce travail supplémentaire pour répondre aux modifications de PPP peuvent apparaître floues ou incorrectement dimensionnées pour l’utilisateur.

Mode de prise en charge des PPP

Les applications de bureau doivent indiquer à Windows s’ils prennent en charge la mise à l’échelle PPP. Par défaut, le système considère les applications bureautiques sans prise en charge PPP et procède à un étirement bitmap de leurs fenêtres. En définissant l’un des modes de prise en charge des PPP disponibles suivants, les applications peuvent explicitement indiquer à Windows comment elles souhaitent gérer la mise à l’échelle PPP :

Sans prise en charge des PPP

Les applications sans prise en charge des PPP s’affichent à une valeur PPP fixe de 96 (100 %). Chaque fois que ces applications sont exécutées sur un écran avec une échelle d’affichage supérieure à 96 PPP, Windows étend la bitmap de l’application à la taille physique attendue. Cela entraîne l’affichage flou de l’application.

Prise en charge des PPP du système

Les applications de bureau avec prise en charge des PPP du système reçoivent généralement les PPP du moniteur connecté principal à partir de l’heure de connexion de l’utilisateur. Lors de l’initialisation, ils mettent en place leur interface utilisateur de manière appropriée (contrôles de dimensionnement, choix des tailles de police, chargement des ressources, etc.) à l’aide de cette valeur de PPP du système. Par conséquent, les applications avec prise en charge des PPP du système ne sont pas mises à l’échelle PPP (étirement bitmap) par Windows sur les affichages au niveau de ce même PPP. Lorsque l’application est déplacée vers un affichage avec un autre facteur d’échelle ou si le facteur d’échelle d’affichage change autrement, Windows met à l’échelle les fenêtres de l’application, ce qui les rend floues. Efficacement, les applications bureautiques avec prise en charge des PPP du système s’affichent uniquement de manière nette à un seul facteur d’échelle d’affichage, ce qui devient flou chaque fois que le PPP change.

Prise en charge des PPP par moniteur et par moniteur (V2)

Il est recommandé que les applications bureautiques soient mises à jour pour utiliser le mode de prise en charge PPP par moniteur, ce qui leur permet de s’afficher immédiatement correctement chaque fois que le PPP change. Lorsqu’une application signale à Windows qu’elle souhaite s’exécuter dans ce mode, Windows ne procède pas à un étirement bitmap de l’application lorsque le PPP change, au lieu d’envoyer WM_DPICHANGED à la fenêtre de l’application. Il incombe ensuite à l’application de gérer le redimensionnement lui-même pour le nouveau PPP. La plupart des infrastructures d’interface utilisateur utilisés par les applications bureautiques (contrôles courants Windows (comctl32), Windows Forms, Windows Presentation Framework, etc.) ne prennent pas en charge la mise à l’échelle automatique des PPP, ce qui oblige les développeurs à redimensionner et repositionner le contenu de leurs fenêtres eux-mêmes.

Il existe deux versions de prise en charge par moniteur dans laquelle une application peut s’inscrire : version 1 et version 2 (PMv2). L’inscription d’un processus en mode de prise en charge PMv2 entraîne :

1. Un avertissement de l’application lorsque le PPP change (les HWND de niveau supérieur et inférieur)
2. L’application affichant les pixels bruts de chaque affichage
3. L’application n’étant jamais mise à l’échelle bitmap par Windows
4. Une zone automatique non cliente (légende de fenêtre, barres de défilement, etc.) Une mise à l’échelle PPP par Windows
5. Des boîtes de dialogue Win32 (à partir de CreateDialog) mises à l’échelle automatiquement par Windows
6. Des ressources bitmap dessinées par thème dans les contrôles courants (cases à cocher, arrière-plans de bouton, etc.) affichées automatiquement au niveau du facteur d’échelle PPP approprié

Lors de l’exécution en mode de prise en charge par moniteur v2, les applications sont averties lorsque leur PPP a changé. Si une application ne se redimensionne pas pour le nouveau PPP, l’interface utilisateur de l’application apparaît trop petite ou trop grande (en fonction de la différence dans les valeurs PPP précédentes et nouvelles).

Le tableau suivant montre comment les applications s’affichent dans différents scénarios :

Mode de prise en charge des PPP par moniteur (V1)

Le mode de prise en charge PPP V1 par moniteur a été introduit avec Windows 8.1. Ce mode de prise en charge des PPP est très limité et offre uniquement les fonctionnalités répertoriées ci-dessous. Il est recommandé que les applications de bureau utilisent le mode de prise en charge par moniteur v2, pris en charge sur Windows 10 1703 ou version ultérieure.

La prise en charge initiale par moniteur offre uniquement les applications suivantes :

1. Les HWND de niveau supérieur sont avertis d’une modification de PPP et ont fourni une nouvelle taille suggérée
2. Windows n’effectue pas d’étirement bitmap de l’interface utilisateur de l’application
3. L’application voit tous les affichages en pixels physiques (voir virtualisation)

Sur Windows 10 1607 ou version ultérieure, les applications PMv1 peuvent également appeler EnableNonClientDpiScaling pendant WM_NCCREATE pour demander que Windows mette correctement à l’échelle la zone non cliente de la fenêtre.

Prise en charge de la mise à l’échelle PPP par moniteur par infrastructure de l’interface utilisateur / Technologie

Le tableau ci-dessous montre le niveau de prise en charge des PPP par moniteur proposé par diverses infrastructures d’interface utilisateur Windows à partir de Windows 10 1703 :

Mise à jour des applications existantes

Pour mettre à jour une application bureautique existante pour gérer correctement la mise à l’échelle PPP, elle doit être mise à jour afin que, au minimum, les parties importantes de son interface utilisateur soient mises à jour pour répondre aux modifications de PPP.

La plupart des applications bureautiques s’exécutent en mode de prise en charge de PPP de système. Les applications avec prise en charge PPP sont généralement mises à l’échelle vers l’écran principal (l’affichage sur lequel la barre d’état système a été installée au moment du démarrage de la session Windows). Lors de changements de PPP, Windows effectue un étirement bitmap de l’interface utilisateur de ces applications, ce qui les rend souvent floues. Lors de la mise à jour d’une application avec prise en charge des PPP du système pour une prise en charge PPP par moniteur, le code qui gère la disposition de l’interface utilisateur doit être mis à jour afin qu’elle soit effectuée non seulement lors de l’initialisation de l’application, mais également chaque fois qu’une notification de modification de PPP (WM_DPICHANGED dans le cas de Win32) est reçue. Cela implique généralement de revoir toutes les hypothèses dans le code que l’interface utilisateur ne doit être mise à l’échelle qu’une seule fois.

En outre, dans le cas de la programmation Win32, de nombreuses API Win32 n’ont pas de contexte de PPP ou d’affichage, de sorte qu’elles retournent uniquement des valeurs par rapport au PPP du système. Il peut être utile de parcourir votre code pour rechercher certaines de ces API et les remplacer par des variantes avec prise en charge DPI. Voici quelques-unes des API courantes qui ont des variantes avec prise en charge DPI :

Il est également judicieux de rechercher des tailles codées en dur dans votre base de code qui supposent un PPP constant, en les remplaçant par du code qui compte correctement pour la mise à l’échelle PPP. Voici un exemple qui incorpore toutes ces suggestions :

Exemple :

L’exemple ci-dessous montre un cas Win32 simplifié de création d’un HWND de niveau inférieur. L’appel à CreateWindow part du principe que l’application s’exécute à 96 PPP (USER_DEFAULT_SCREEN_DPI constante), et que ni la taille ni la position du bouton ne seront correctes à des PPP supérieurs :

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); 
} 

Le code mis à jour ci-dessous montre :

1. Le code de création de la fenêtre met à l’échelle PPP la position et la taille du HWND enfant au PPP de sa fenêtre parentale
2. Réponse au changement de PPP en repositionnant et en redimensionnant le HWND de niveau inférieur
3. Tailles codées en dur supprimées et remplacées par du code qui répond aux modifications de PPP

#define INITIALX_96DPI 50 
#define INITIALY_96DPI 50 
#define INITIALWIDTH_96DPI 100 
#define INITIALHEIGHT_96DPI 50 

// DPI scale the position and size of the button control 
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: 
{ 
    // Add a button 
    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: 
{ 
    // Find the button and resize it 
    HWND hWndButton = FindWindowEx(hWnd, NULL, NULL, NULL); 
    if (hWndButton != NULL) 
    { 
        UpdateButtonLayoutForDpi(hWndButton); 
    } 
} 
break; 

Lors de la mise à jour d’une application avec prise en charge des PPP du système, voici quelques étapes courantes à suivre :

1. Marquez le processus comme prenant en charge les PPP par moniteur (V2) à l’aide d’un manifeste d’application (ou d’une autre méthode, selon la ou les infrastructure(s) d’interface utilisateur utilisés).
2. Rendez la logique de disposition de l’interface utilisateur réutilisable et déplacez-la hors du code d’initialisation de l’application afin qu’elle puisse être réutilisée lorsqu’une modification de PPP se produit (WM_DPICHANGED dans le cas de la programmation Windows (Win32)).
3. Invalidez tout code qui suppose que les données sensibles aux PPP (PPP/polices/tailles/etc.) n’ont jamais besoin d’être mises à jour. Il s’agit d’une pratique très courante pour mettre en cache les tailles de police et les valeurs PPP lors de l’initialisation du processus. Lors de la mise à jour d’une application pour qu’elle prenne en charge les PPP par moniteur, les données sensibles aux PPP doivent être réévaluées chaque fois qu’un nouveau PPP est rencontré.
4. Lorsqu’une modification de PPP se produit, rechargez (ou rerastérisez) toutes les ressources bitmap pour le nouveau PPP ou, éventuellement, étirez les ressources actuellement chargées jusqu’à la taille correcte.
5. Effectuez un Grep pour les API qui ne prennent pas en charge les PPP par moniteur et remplacez-les par des API prenant en charge les PPP par moniteur (le cas échéant). Exemple : remplacez GetSystemMetrics par GetSystemMetricsForDpi.
6. Testez votre application sur un système multi-affichage/multi-PPP.
7. Pour toutes les fenêtres de niveau supérieur de votre application que vous ne parvenez pas à mettre correctement à l’échelle PPP, utilisez la mise à l’échelle PPP en mode mixte (décrite ci-dessous) pour autoriser l’étirement bitmap de ces fenêtres de premier niveau par le système.

Mise à l’échelle PPP en mode mixte (mise à l’échelle PPP du sous-processus)

Lors de la mise à jour d’une application permettant la prise en charge des PPP par moniteur, il peut parfois devenir difficile ou impossible de mettre à jour chaque fenêtre de l’application en une seule fois. Cela peut simplement être dû au temps et à l’effort nécessaires pour mettre à jour et tester toute l’interface utilisateur, ou parce que vous ne possédez pas tout le code de l’interface utilisateur que vous devez exécuter (si votre application charge peut-être une interface utilisateur tierce). Dans ces situations, Windows offre un moyen de découvrir facilement la prise en charge par moniteur en vous permettant d’exécuter certaines de vos fenêtres d’application (de premier niveau uniquement) dans le mode avec prise en charge PPP d’origine, tandis que vous concentrez votre temps et votre énergie à mettre à jour les parties les plus importantes de votre interface utilisateur.

Voici une illustration de ce que cela pourrait ressembler : vous mettez à jour l’interface utilisateur de votre application principale (« Fenêtre principale » dans l’illustration) pour qu’elle s’exécute avec une prise en charge des PPP par moniteur pendant que vous exécutez d’autres fenêtres en mode existant (« Fenêtre secondaire »).

Avant la mise à jour anniversaire Windows 10 (1607), le mode de prise en charge d’un processus était une propriété à l’échelle du processus. À compter de la mise à jour anniversaire Windows 10, cette propriété peut désormais être définie par fenêtre de premier niveau. (Les fenêtres de second niveau doivent continuer à correspondre à la taille de mise à l’échelle de leur parent.) Une fenêtre de premier niveau est définie comme une fenêtre sans parent. Il s’agit généralement d’une fenêtre « normale » avec des boutons de réduction, d’agrandissement et de fermeture. Le scénario pour lequel la prise en charge des PPP de sous-processus est prévue est celui d’une interface utilisateur secondaire mise à l’échelle par Windows (bitmap étirée) pendant que vous concentrez votre temps et vos ressources sur la mise à jour de votre interface utilisateur principale.

Pour activer la prise en charge des PPP de sous-processus, appelez SetThreadDpiAwarenessContext avant et après les appels de création de fenêtre. La fenêtre créée est associée à la prise en charge des PPP que vous définissez via SetThreadDpiAwarenessContext. Utilisez le deuxième appel pour restaurer la prise en charge PPP du thread actuel.

Bien que l’utilisation de la mise à l’échelle PPP des sous-processus vous permet de vous appuyer sur Windows pour effectuer une partie de la mise à l’échelle PPP pour votre application, elle peut augmenter la complexité de votre application. Il est important de comprendre les inconvénients de cette approche et la nature des complexités qu’elle introduit. Pour plus d’informations sur la prise en charge des PPP de sous-processus, consultez Mise à l’échelle PPP en mode mixte et API avec prise en charge PPP.

Test de vos modifications

Une fois que vous avez mis à jour votre application pour une prise en charge des PPP par moniteur, il est important de valider que votre application répond correctement aux modifications apportées aux PPP dans un environnement à PPP mixtes. Voici quelques spécificités à tester :

1. Déplacement des fenêtres d’application entre les affichages de différentes valeurs de PPP
2. Démarrage de votre application sur les affichages de différentes valeurs de PPP
3. Modification du facteur d’échelle de votre moniteur pendant l’exécution de l’application
4. Modification de l’affichage que vous utilisez comme affichage principal, déconnexion de Windows, puis nouveau test de votre application après la connexion. Cela est particulièrement utile pour rechercher du code qui utilise des tailles/dimensions codées en dur.

Erreurs courantes (Win32)

Ne pas utiliser le rectangle suggéré fourni dans WM_DPICHANGED

Lorsque Windows envoie une fenêtre d’application à un message WM_DPICHANGED, ce message inclut un rectangle suggéré que vous devez utiliser pour redimensionner votre fenêtre. Il est essentiel que votre application utilise ce rectangle pour se redimensionner, comme suit :

1. Vérifiez que le curseur de la souris reste dans la même position relative sur la fenêtre lors du glissement entre les affichages
2. Empêchez la fenêtre de l’application d’entrer dans un cycle de changement de PPP récursif où une modification de PPP déclenche une modification de PPP ultérieure, ce qui déclenche une autre modification de PPP.

Si vous avez des exigences spécifiques à l’application qui vous empêchent d’utiliser le rectangle suggéré que Windows fournit dans le message WM_DPICHANGED, consultez WM_GETDPISCALEDSIZE. Ce message peut être utilisé pour donner à Windows une taille souhaitée que vous souhaitez utiliser une fois que la modification de PPP s’est produite, tout en évitant les problèmes décrits ci-dessus.

Manque de documentation sur la virtualisation

Lorsqu’un HWND ou un processus s’exécute sans prise en charge des PPP ou avec prise en charge des PPP du système, Windows peut effectuer un étirement bitmap. Lorsque cela se produit, Windows met à l’échelle et convertit les informations sensibles aux PPP de certaines API en espace de coordonnées du thread appelant. Par exemple, si un thread sans prise en charge de PPP interroge la taille de l’écran lors de l’exécution sur un affichage haute résolution, Windows virtualise la réponse donnée à l’application comme si l’écran se trouvait dans 96 PPP. Sinon, lorsqu’un thread avec prise en charge les ppp du système interagit avec un affichage doté d’un autre PPP que celui utilisé lors du démarrage de la session de l’utilisateur actuel, Windows met à l’échelle certains appels d’API dans l’espace de coordonnées que le HWND utiliserait s’il s’exécutait à son facteur d’échelle PPP d’origine.

Lorsque vous mettez à jour votre application de bureau vers une mise à l’échelle PPP correctement, il peut être difficile de savoir quels appels d’API peuvent retourner des valeurs virtualisées en fonction du contexte de thread. Ces informations ne sont pas suffisamment documentées par Microsoft. N’oubliez pas que si vous appelez une API système à partir d’un contexte de thread sans prise en charge des PPP ou avec prise en charge des PPP du système, la valeur de retour peut être virtualisée. Par conséquent, assurez-vous que votre thread s’exécute dans le contexte PPP que vous attendez lors de l’interaction avec l’écran ou les fenêtres individuelles. Lorsque vous modifiez temporairement le contexte PPP d’un thread à l’aide de SetThreadDpiAwarenessContext, veillez à restaurer l’ancien contexte lorsque vous avez terminé pour éviter de provoquer un comportement incorrect ailleurs dans votre application.

De nombreuses API Windows n’ont pas de contexte PPP

De nombreuses API Windows héritées n’incluent pas de contexte PPP ou HWND dans le cadre de leur interface. Par conséquent, les développeurs doivent souvent effectuer des tâches supplémentaires pour gérer la mise à l’échelle des informations sensibles aux PPP, telles que les tailles, les points ou les icônes. Par exemple, les développeurs qui utilisent LoadIcon doivent soit des icônes d’étirement bitmap, soit utiliser d’autres API pour charger des icônes de taille correcte pour la résolution appropriée, comme LoadImage.

Réinitialisation forcée de la prise en charge des PPP à l’échelle du processus

En général, le mode de prise en charge des PPP de votre processus ne peut pas être modifié après l’initialisation du processus. Toutefois, Windows peut forcer la modification du mode de prise en charge des PPP de votre processus si vous tentez d’aller à l’encontre de l’exigence d’avoir tous les HWND d’une arborescence de fenêtres sur le même mode de prise en charge des PPP. Sur toutes les versions de Windows, à partir de Windows 10 1703, il n’est pas possible d’avoir différents HWND dans une arborescence HWND exécutée dans différents modes de prise en charge des PPP. Si vous tentez de créer une relation enfant-parent qui interrompt cette règle, la prise en compte de l’ensemble du processus peut être réinitialisée. Cela peut être déclenché par :

1. Un appel CreateWindow où la fenêtre parentale passée est d’un mode de prise en charge de PPP différent du thread appelant.
2. Un appel SetParent où les deux fenêtres sont associées à différents modes de prise en charge des PPP.

Le tableau ci-dessous montre ce qu’il se passe si vous tentez d’enfreindre cette règle :

Rubriques connexes

Référence sur l’API PPP élevée

Mise à l’échelle PPP en mode mixte et API avec prise en charge PPP.