Sviluppo di applicazioni desktop DPI elevate in Windows

Questo contenuto è destinato agli sviluppatori che cercano di aggiornare le applicazioni desktop per gestire le modifiche del fattore di scala di visualizzazione (punti per pollice o DPI) in modo dinamico, consentendo alle applicazioni di essere nitide su qualsiasi display su cui viene eseguito il rendering.

Per iniziare, se stai creando una nuova app di Windows da zero, è consigliabile creare un'applicazione piattaforma UWP (Universal Windows Platform) (UWP). Le applicazioni UWP vengono ridimensionate automaticamente e dinamicamente per ogni visualizzazione in cui sono in esecuzione.

Applicazioni desktop che usano tecnologie di programmazione Windows meno recenti (programmazione Win32 non elaborata, Windows Form, Windows Presentation Framework (WPF) e così via. non è in grado di gestire automaticamente il ridimensionamento DPI senza ulteriori attività di sviluppo. Senza questo lavoro, le applicazioni appariranno sfocate o di dimensioni non corrette in molti scenari di utilizzo comuni. Questo documento fornisce contesto e informazioni su ciò che è coinvolto nell'aggiornamento di un'applicazione desktop per il rendering corretto.

Visualizza fattore di scala e DPI

Con l'avanzare della tecnologia di visualizzazione, i produttori di pannelli di visualizzazione hanno compresso un numero crescente di pixel in ogni unità di spazio fisico sui loro pannelli. Questo ha portato i punti per pollice (DPI) dei pannelli di display moderni molto più alti di quelli storicamente. In passato, la maggior parte dei display aveva 96 pixel per pollice lineare dello spazio fisico (96 DPI); nel 2017, i display con quasi 300 DPI o superiori sono immediatamente disponibili.

La maggior parte dei framework dell'interfaccia utente desktop legacy presuppone che il dpi di visualizzazione non cambierà durante la durata del processo. Questo presupposto non contiene più true, con i DPI visualizzati che cambiano più volte per tutta la durata di un processo dell'applicazione. Alcuni scenari comuni in cui il fattore di scala di visualizzazione/DPI cambia:

• Configurazioni con più monitor in cui ogni visualizzazione ha un fattore di scala diverso e l'applicazione viene spostata da uno schermo a un altro (ad esempio un display 4K e un display a 1080p)
• Ancoraggio e scollegamento di un portatile con valori DPI alti con un display esterno con valori DPI bassi (o viceversa)
• Connessione tramite Desktop remoto da un portatile/tablet con valori DPI elevati a un dispositivo con valori DPI bassi (o viceversa)
• Modifica delle impostazioni del fattore di scalabilità di visualizzazione durante l'esecuzione delle applicazioni

In questi scenari, le applicazioni UWP si ridisegnano automaticamente per il nuovo DPI. Per impostazione predefinita, e senza lavoro aggiuntivo per sviluppatori, le applicazioni desktop non lo fanno. Le applicazioni desktop che non eseguono questo lavoro aggiuntivo per rispondere alle modifiche DPI possono apparire sfocate o non correttamente ridimensionate all'utente.

Modalità di riconoscimento DPI

Le applicazioni desktop devono indicare a Windows se supportano il ridimensionamento DPI. Per impostazione predefinita, il sistema considera le applicazioni desktop DPI non consapevoli e bitmap estende le finestre. Impostando una delle modalità di riconoscimento DPI disponibili seguenti, le applicazioni possono indicare esplicitamente a Windows come vogliono gestire il ridimensionamento DPI:

DPI non a conoscenza

Il rendering delle applicazioni dpi non consapevoli viene eseguito con un valore DPI fisso pari a 96 (100%). Ogni volta che queste applicazioni vengono eseguite su uno schermo con una scala di visualizzazione maggiore di 96 DPI, Windows estenderà la bitmap dell'applicazione alle dimensioni fisiche previste. Ciò comporta la visualizzazione sfocata dell'applicazione.

Riconoscimento DPI del sistema

Le applicazioni desktop con riconoscimento DPI di sistema ricevono in genere il valore DPI del monitoraggio connesso primario al momento dell'accesso dell'utente. Durante l'inizializzazione, il layout dell'interfaccia utente viene eseguito in modo appropriato (controlli di ridimensionamento, scelta delle dimensioni del carattere, caricamento di asset e così via) usando tale valore DPI di sistema. Di conseguenza, le applicazioni con riconoscimento DPI di sistema non vengono ridimensionate (con estensione bitmap) da Windows per visualizzare il rendering in corrispondenza di tale singolo DPI. Quando l'applicazione viene spostata in uno schermo con un fattore di scala diverso o se il fattore di scala di visualizzazione cambia in caso contrario, Windows ridimensiona le finestre dell'applicazione, rendendole sfocate. In effetti, le applicazioni desktop compatibili con DPI di sistema eseguono il rendering in modo nitido solo in un singolo fattore di scala dello schermo, diventando sfocato ogni volta che cambia il valore DPI.

Riconoscimento DPI per monitor e per monitor (V2)

È consigliabile aggiornare le applicazioni desktop per usare la modalità di riconoscimento DPI per monitor, consentendo loro di eseguire immediatamente il rendering corretto ogni volta che cambia il valore DPI. Quando un'applicazione segnala a Windows che vuole essere eseguita in questa modalità, Windows non estenderà l'applicazione quando cambia il valore DPI, inviando invece WM_DPICHANGED alla finestra dell'applicazione. È quindi responsabilità completa dell'applicazione gestire il ridimensionamento per il nuovo DPI. La maggior parte dei framework dell'interfaccia utente usati dalle applicazioni desktop (controlli comuni di Windows (comctl32), Windows Form, Windows Presentation Framework e così via. non supportano il ridimensionamento DPI automatico, richiedendo agli sviluppatori di ridimensionare e riposizionare il contenuto delle finestre stesse.

Esistono due versioni di Per-Monitor che un'applicazione può registrarsi come: versione 1 e versione 2 (PMv2). La registrazione di un processo come in esecuzione in modalità di riconoscimento PMv2 comporta:

1. L'applicazione riceve una notifica quando cambia il valore DPI (sia i HWND di primo livello che figlio)
2. L'applicazione visualizza i pixel non elaborati di ogni visualizzazione
3. L'applicazione non viene mai ridimensionata dalla bitmap di Windows
4. Area automatica non client (finestra didascalia, barre di scorrimento e così via) Ridimensionamento DPI per Windows
5. Finestre di dialogo Win32 (da CreateDialog) ridimensionate automaticamente da Windows
6. Asset bitmap disegnati dal tema in controlli comuni (caselle di controllo, sfondi dei pulsanti e così via) di cui viene eseguito automaticamente il rendering al fattore di scala DPI appropriato

Quando è in esecuzione in modalità riconoscimento per Monitor v2, le applicazioni ricevono una notifica quando il valore DPI è cambiato. Se un'applicazione non viene ridimensionata per il nuovo dpi, l'interfaccia utente dell'applicazione apparirà troppo piccola o troppo grande (a seconda della differenza nei valori DPI precedenti e nuovi).

La tabella seguente illustra il rendering delle applicazioni in scenari diversi:

Riconoscimento DPI per monitor (V1)

La modalità di riconoscimento DPI V1 (PMv1) per monitor è stata introdotta con Windows 8.1. Questa modalità di riconoscimento DPI è molto limitata e offre solo le funzionalità elencate di seguito. È consigliabile che le applicazioni desktop usino la modalità di riconoscimento per Monitor v2, supportata in Windows 10 1703 o versione successiva.

Il supporto iniziale per la consapevolezza per monitor offre solo le applicazioni seguenti:

1. I HWND di primo livello ricevono una notifica di modifica dpi e hanno fornito una nuova dimensione suggerita
2. Windows non estenderà l'interfaccia utente dell'applicazione
3. L'applicazione vede tutti i display in pixel fisici (vedere la virtualizzazione)

In Windows 10 1607 o versione successiva, le applicazioni PMv1 possono anche chiamare EnableNonClientDpiScaling durante WM_NCCREATE per richiedere che Windows ridimensiona correttamente l'area non client della finestra.

Supporto per il ridimensionamento DPI per monitor by UI Framework/Technology

La tabella seguente mostra il livello di supporto di riconoscimento DPI per monitor offerto da vari framework dell'interfaccia utente di Windows a partire da Windows 10 1703:

Aggiornamento di applicazioni esistenti

Per aggiornare correttamente un'applicazione desktop esistente per gestire correttamente il ridimensionamento DPI, è necessario aggiornarla in modo che, almeno, le parti importanti dell'interfaccia utente vengano aggiornate per rispondere alle modifiche dpi.

La maggior parte delle applicazioni desktop viene eseguita in modalità di riconoscimento DPI di sistema. Le applicazioni compatibili con dpi di sistema vengono in genere ridimensionate al valore DPI della visualizzazione primaria (la visualizzazione in cui si trovava l'area di notifica al momento dell'avvio della sessione di Windows). Quando cambia il valore DPI, Windows estenderà l'interfaccia utente di queste applicazioni, che spesso comporta la sfocatura. Quando si aggiorna un'applicazione compatibile con DPI di sistema per diventare compatibile con dpi per monitor, il codice che gestisce il layout dell'interfaccia utente deve essere aggiornato in modo che venga eseguito non solo durante l'inizializzazione dell'applicazione, ma anche ogni volta che viene ricevuta una notifica di modifica DPI (WM_DPICHANGED nel caso di Win32). Ciò comporta in genere la revisione di eventuali presupposti nel codice che l'interfaccia utente deve essere ridimensionata una sola volta.

Inoltre, nel caso della programmazione Win32, molte API Win32 non hanno alcun contesto DPI o di visualizzazione, quindi restituiscono solo valori relativi alla dpi di sistema. Può essere utile usare il codice per cercare alcune di queste API e sostituirle con varianti compatibili con DPI. Alcune delle API comuni con varianti compatibili con DPI sono:

È anche consigliabile cercare dimensioni hardcoded nella codebase che presuppongono una costante DPI, sostituendole con codice che considera correttamente il ridimensionamento DPI. Di seguito è riportato un esempio che incorpora tutti questi suggerimenti:

Esempio:

L'esempio seguente illustra un caso Win32 semplificato per la creazione di un HWND figlio. La chiamata a CreateWindow presuppone che l'applicazione sia in esecuzione a 96 DPI (USER_DEFAULT_SCREEN_DPI costante) e che nessuna delle dimensioni e della posizione del pulsante sia corretta in dpi superiori:

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

Il codice aggiornato seguente mostra:

1. Valore DPI del codice di creazione della finestra che ridimensiona la posizione e le dimensioni del valore HWND figlio per il valore DPI della finestra padre
2. Risposta alla modifica dpi riposizionando e ridimensionando l'HWND figlio
3. Dimensioni hardcoded rimosse e sostituite con codice che risponde alle modifiche DPI

#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; 

Quando si aggiorna un'applicazione compatibile con DPI di sistema, alcuni passaggi comuni da seguire sono:

1. Contrassegnare il processo come compatibile con DPI per monitor (V2) usando un manifesto dell'applicazione (o un altro metodo, a seconda dei framework dell'interfaccia utente usati).
2. Rendere riutilizzabile la logica del layout dell'interfaccia utente e spostarla dal codice di inizializzazione dell'applicazione in modo che possa essere riutilizzata quando si verifica una modifica DPI (WM_DPICHANGED nel caso della programmazione Di Windows (Win32).
3. Invalidare qualsiasi codice che presuppone che i dati sensibili dpi (DPI/fonts/sizes/etc.) non debbano mai essere aggiornati. È pratica molto comune memorizzare nella cache le dimensioni dei caratteri e i valori DPI durante l'inizializzazione del processo. Quando si aggiorna un'applicazione in modo che diventi compatibile con dpi per monitor, è necessario rivalutare i dati sensibili ai valori DPI ogni volta che viene rilevato un nuovo DPI.
4. Quando si verifica una modifica dpi, ricaricare (o ri-rasterizzare) qualsiasi asset bitmap per il nuovo DPI o, facoltativamente, la bitmap estende gli asset attualmente caricati alle dimensioni corrette.
5. Grep per le API che non sono compatibili con dpi per monitor e sostituirle con le API compatibili con DPI per monitor (se applicabile). Esempio: sostituire GetSystemMetrics con GetSystemMetricsForDpi.
6. Testare l'applicazione in un sistema multi-display/multi-DPI.
7. Per le finestre di primo livello dell'applicazione che non è possibile aggiornare correttamente alla scala DPI, usare il ridimensionamento DPI in modalità mista (descritto di seguito) per consentire l'estensione bitmap di queste finestre di primo livello dal sistema.

Ridimensionamento DPI in modalità mista (ridimensionamento DPI del sottoprocesso)

Quando si aggiorna un'applicazione per supportare la consapevolezza DPI per monitor, a volte può diventare poco pratico o impossibile aggiornare ogni finestra nell'applicazione in un'unica operazione. Questo può essere semplicemente dovuto al tempo e allo sforzo necessario per aggiornare e testare tutta l'interfaccia utente o perché non si è proprietari di tutto il codice dell'interfaccia utente che è necessario eseguire (se l'applicazione potrebbe caricare l'interfaccia utente di terze parti). In queste situazioni, Windows offre un modo per semplificare il mondo della consapevolezza per ogni monitor consentendo di eseguire alcune delle finestre dell'applicazione (solo di primo livello) nella modalità originale di riconoscimento DPI, mentre ti concentri sul tempo e sull'energia aggiornando le parti più importanti dell'interfaccia utente.

Di seguito è riportata un'illustrazione dell'aspetto che potrebbe essere simile al seguente: si aggiorna l'interfaccia utente principale dell'applicazione ("Finestra principale" nell'illustrazione) per l'esecuzione con riconoscimento DPI per monitor mentre si eseguono altre finestre nella modalità esistente ("Finestra secondaria").

Prima dell'aggiornamento dell'anniversario di Windows 10 (1607), la modalità di riconoscimento DPI di un processo era una proprietà a livello di processo. A partire dall'aggiornamento dell'anniversario di Windows 10, questa proprietà può ora essere impostata per ogni finestra di primo livello . Le finestre figlio devono continuare a corrispondere alle dimensioni di ridimensionamento del padre. Una finestra di primo livello è definita come finestra senza elemento padre. Si tratta in genere di una finestra "normale" con pulsanti minimi, ingrandisci e chiudi. Lo scenario per il quale la consapevolezza DPI del sottoprocesso è destinata ad avere l'interfaccia utente secondaria ridimensionata da Windows (bitmap estesa) mentre si concentra il tempo e le risorse sull'aggiornamento dell'interfaccia utente primaria.

Per abilitare la consapevolezza dpi del sottoprocesso, chiamare SetThreadDpiAwarenessContext prima e dopo le chiamate di creazione di finestre. La finestra creata verrà associata alla consapevolezza DPI impostata tramite SetThreadDpiAwarenessContext. Usare la seconda chiamata per ripristinare la consapevolezza DPI del thread corrente.

L'uso del ridimensionamento DPI del sottoprocesso consente di fare affidamento su Windows per eseguire alcune delle operazioni di ridimensionamento DPI per l'applicazione, ma può aumentare la complessità dell'applicazione. È importante comprendere gli svantaggi di questo approccio e la natura delle complessità introdotte. Per altre informazioni sulla consapevolezza dpi del sottoprocesso, vedere Ridimensionamento DPI in modalità mista e API compatibili con DPI.

Test delle modifiche

Dopo aver aggiornato l'applicazione in modo che diventi compatibile con dpi per monitor, è importante convalidare correttamente la risposta corretta dell'applicazione alle modifiche DPI in un ambiente DPI misto. Alcune specifiche per il test includono:

1. Spostamento delle finestre dell'applicazione avanti e indietro tra le visualizzazioni di valori DPI diversi
2. Avvio dell'applicazione in visualizzazione di valori DPI diversi
3. Modifica del fattore di scala per il monitoraggio durante l'esecuzione dell'applicazione
4. Modifica della visualizzazione usata come visualizzazione primaria, disconnessione da Windows, quindi nuovo test dell'applicazione dopo l'accesso. Ciò è particolarmente utile per trovare codice che usa dimensioni/dimensioni hardcoded.

Problemi comuni (Win32)

Non usare il rettangolo suggerito fornito in WM_DPICHANGED

Quando Windows invia alla finestra dell'applicazione un messaggio di WM_DPICHANGED , questo messaggio include un rettangolo suggerito da usare per ridimensionare la finestra. È fondamentale che l'applicazione usi questo rettangolo per ridimensionarsi, come segue:

1. Assicurarsi che il cursore del mouse rimanga nella stessa posizione relativa della finestra durante il trascinamento tra i display
2. Impedisci alla finestra dell'applicazione di accedere a un ciclo di modifica dpi ricorsivo in cui una modifica DPI attiva una modifica DPI successiva, che attiva un'altra modifica DPI.

Se sono presenti requisiti specifici dell'applicazione che impediscono di usare il rettangolo suggerito fornito da Windows nel messaggio di WM_DPICHANGED, vedere WM_GETDPISCALEDSIZE. Questo messaggio può essere usato per assegnare a Windows una dimensione desiderata che si desidera utilizzare una volta apportata la modifica dpi, evitando comunque i problemi descritti in precedenza.

Mancanza di documentazione sulla virtualizzazione

Quando un HWND o un processo è in esecuzione come dpi non consapevole o dpi di sistema, può essere esteso da Windows. In questo caso, Windows ridimensiona e converte le informazioni sensibili dpi da alcune API allo spazio delle coordinate del thread chiamante. Ad esempio, se un thread dpi-unware esegue una query sulle dimensioni dello schermo durante l'esecuzione su uno schermo con valori DPI elevati, Windows virtualizzerà la risposta fornita all'applicazione come se lo schermo fosse in unità DPI 96. In alternativa, quando un thread compatibile con DPI di sistema interagisce con una visualizzazione con valori DPI diversi rispetto a quando è stata avviata la sessione dell'utente corrente, Windows ridimensiona alcune chiamate API nello spazio di coordinate usato da HWND se fosse in esecuzione con il fattore di scala DPI originale.

Quando si aggiorna correttamente l'applicazione desktop alla scalabilità DPI, può essere difficile sapere quali chiamate API possono restituire valori virtualizzati in base al contesto del thread; queste informazioni non sono attualmente sufficientemente documentate da Microsoft. Tenere presente che se si chiama un'API di sistema da un contesto di thread con riconoscimento DPI o compatibile con DPI di sistema, il valore restituito potrebbe essere virtualizzato. Di conseguenza, assicurarsi che il thread sia in esecuzione nel contesto DPI previsto durante l'interazione con lo schermo o con le singole finestre. Quando si modifica temporaneamente il contesto DPI di un thread usando SetThreadDpiAwarenessContext, assicurarsi di ripristinare il contesto precedente al termine per evitare di causare comportamenti errati altrove nell'applicazione.

Molte API di Windows non hanno un contesto DPI

Molte API Windows legacy non includono un contesto DPI o HWND come parte della relativa interfaccia. Di conseguenza, gli sviluppatori spesso devono eseguire operazioni aggiuntive per gestire il ridimensionamento di qualsiasi informazione sensibile ai DPI, ad esempio dimensioni, punti o icone. Ad esempio, gli sviluppatori che usano LoadIcon devono usare icone caricate con estensione bitmap o usare API alternative per caricare icone di dimensioni corrette per i valori DPI appropriati, ad esempio LoadImage.

Reimpostazione forzata della consapevolezza DPI a livello di processo

In generale, la modalità di riconoscimento DPI del processo non può essere modificata dopo l'inizializzazione del processo. Windows può tuttavia modificare forzatamente la modalità di consapevolezza DPI del processo se si tenta di interrompere il requisito che tutti i HWND in un albero delle finestre abbiano la stessa modalità di riconoscimento DPI. In tutte le versioni di Windows, a partire da Windows 10 1703, non è possibile avere diversi HWND in un albero HWND eseguito in diverse modalità di riconoscimento DPI. Se si tenta di creare una relazione padre figlio che interrompe questa regola, è possibile reimpostare la consapevolezza DPI dell'intero processo. Questo può essere attivato da:

1. Una chiamata CreateWindow in cui la finestra padre passata è di una modalità di riconoscimento DPI diversa rispetto al thread chiamante.
2. Chiamata SetParent in cui le due finestre sono associate a diverse modalità di riconoscimento DPI.

La tabella seguente illustra cosa accade se si tenta di violare questa regola:

Argomenti correlati

Informazioni di riferimento sulle API DPI elevate

Ridimensionamento DPI in modalità mista e API compatibili con DPI.