WPF: Indipendenza dalla Risoluzione Video
Una delle caratteristiche chiave di WPF, che lo differenzia da architetture alternative come le Windows Form e ASP.NET, consiste nel suo sistema di misura indipendente dalla risoluzione. In altre parole, WPF non utilizza più il PIXEL come unità di misura per indicare la dimensione di un bottone, di un rettangolo o di un video; infatti, il pixel non ha una dimensione standard: ce ne stanno per esempio 96 in un pollice (2,54 cm) per un monitor LCD da 19’’, ma ben 130 in uno schermo di un notebook recente; per rendersi conto di questo serve solo un righello: misurate la larghezza del vostro monitor (33,87 cm nel primo caso, 32,82 nel secondo) e la dividete per la risoluzione orizzontale (1280 nel primo, 1680 nel secondo), otterrete così la larghezza di un pixel in centimetri, che poi potete trasformare in DPI (pixel per pollice) con una semplice equivalenza.
L’immediata conseguenza di indicare le misure in pixel, e questo lo sanno anche i sassi, è che l'interfaccia risulta più grande al diminuire della densità: se cambiate la risoluzione del vostro schermo da 1280x1024 a 800x600 e mantenete uguale l’area visibile vi troverete gli oggetti più grandi del 60% perché di fatto questa è la crescita che ciascun pixel ha avuto; apro e chiudo una parentesi, anche questo tutti lo sanno ma repetita iuvant: i monitor LCD hanno una risoluzione nativa e cambiarla equivale a fare sì che il software del monitor (NON della scheda grafica) riscali la nuova risoluzione su quella nativa, con un peggioramento evidente della qualità; come vedremo più avanti, la strada da seguire per ingrandire l’immagine è agire sui DPI, NON sulla risoluzione.
Ma allora, che unità di misura utilizza WPF? Il millimetro, il centimetro, il pollice, il metro? Fuochino. Nel senso che utilizza un’unità di misura appunto indipendente dalla risoluzione; quindi invece di dire che un bottone è largo 100 pixel, imposta per esempio la sua misura a 2 centimetri; a quel punto, quando l’utente si sposta su un monitor che ha una densità di pixel diversa –come negli esempi sopra- il bottone dovrebbe continuare a misurare 2 centimetri.
Perché dico dovrebbe? Beh, perfino chi ha già sviluppato in WPF -e non si è posto il problema- probabilmente non non ha ancora notato la differenza nel sistema di misura di WPF rispetto agli altri; anzi, avrà notato il contrario: cambiando monitor, anche gli oggetti WPF cambiano di dimensione; addirittura, rimanendo sullo stesso monitor e cambiando risoluzione, le applicazioni WPF scalano esattamente come le Windows Forms e le applicazioni WEB. Spiegherò il perché di tutto questo fra un momento.
Lasciatemi prima dire, anche se è un dettaglio, qual è l’unità di misura indipendente dalla risoluzione (che di seguito chiamerò DIU: Device Independent Unit) che usa WPF; tenetevi forte: 0,026458333333 centimetri; comodo da ricordare, vero ;-) ? Per avere un’idea più pratica, considerate che è circa un quarto di millimetro. Ma probabilmente la fissiamo meglio in mente se consideriamo che ci sono esattamente 96 DIU ogni 2,54 centimetri. In altre parole 1 DIU = 1/96 di pollice. Quindi se vogliamo fare un bottone largo 1 pollice dovremo indicare Width="96", e ovviamente 10 centimetri misurano 377,95 DIU.
Torniamo all'osservazione di prima: prendo un righello, lancio Visual Studio, metto sulla form WPF un bottone da 96 DIU, lo misuro e... mi accorgo che NON è largo necessariamente un centimetro! Abbasso la risoluzione, diventa più largo, vado su un altro PC e cambia ancora... ma allora dov’è la blasonata RESOLUTION INDEPENDENCE di WPF? Il punto è che WPF si basa sulle impostazioni di sistema, non sulle impostazioni del device fisico (il monitor); se ci pensate un momento, questo ha perfettamente senso: come fa il vostro sistema a sapere quanti centimetri è largo il vostro monitor? Come fa a sapere la distanza del telo dal prioettore collegato alla vostra uscita video, visto che le dimensioni dell’immagine dipendono da questa? Non lo sa. A meno che non siate voi a dirglielo. Come? Fate le misurazioni (vedi l’esempio introduttivo di questo post, dove calcolavo 130 DPI) e specificatele nel Pannello di Controllo (sezione DPI Scaling) come indicato di seguito:
A questo punto impostate Width="377.95" nei parametri del bottone (sì, avete letto bene: i DIU si specificano in double) , prendete il righello e verificate se non ci credete: il bottone è largo 10 centimetri, su qualunque monitor e, naturalmente, anche se lo stampate su una LASER da 1200 DPI o su una ad aghi!
Provate a fare la stessa cosa con un’applicazione tradizionale in finestra o WEB: non si può, o meglio in teoria potreste farlo ma non certo utilizzando un’unica misura (377,95): dovreste contare quanti pixel ci vogliono per fare 10 centimentri e cambiare la dimensione di conseguenza di dispositivo in dispostivo; per curiosità e piacere di calcolo: se impostate Width="377.95", WPF accende ben 512 pixel sul monitor da 130 DPI in risoluzione nativa di 1680x1050 e solo 236 su un monitor largo uguale che abbia però una risoluzione nativa di 800x600, ma entrambi i casi la misura è sempre 10 centimetri, e in tutti i casi la misura che voi avete specificato con WPF è sempre la stessa (377,95 DIU)!
Ora anticipo la prossima obiezione, che qualcuno di persona mi ha già fatto: d’accordo, ora è chiaro come tracciare misure fisse indipendenti dalla risoluzione. Ma a me non interessa. Io voglio continuare a beneficiare del fatto che sia l’utente a scegliere le dimensioni della mia applicazione semplicemente cambiando la risoluzione del monitor oppure, ma solo se è lui a deciderlo, modificando il DPI Scaling. Ebbene, non a caso il DIU misura 1/96 di pollice; infatti, per default quando installate Windows, la scala è impostata 96 DPI (vedi immagine sopra). Ciò significa che, se non viene cambiato il valore 96 di default, 1 DIU = 1 PIXEL. Quindi sviluppando in WPF avete entrambi i benefici: per default, funziona tutto come prima, ma se la vostra applicazione deve gestire dimensioni reali basta che chiediate all’utente di impostare DPI Settings al valore corretto per il suo monitor (semplicmente dividendo la larghezza del monitor per la risoluzione orizzontale); immaginate per esempio una calcolatrice touch screen: sarebbe molto scomodo che, portandola sul un monitor da 52 pollici full HD, occorresse uno spillo per premere i bottoni sul video per evitare che la punta del vostro dito pigi 3 bottoni insieme.
Infine, e sarà argomento di un prossimo post, seguendo questa strada con WPF diventa semplice scalare gli oggetti di interfaccia: avete mai visto un’applicazione che quando è portata a pieno schermo ingrandisce in proporzione tutti gli elementi contenuti nella finestra? Very complicato da implementare in un’applicazione tradizionale. Questo è il motivo per cui spesso si leggono warning del tipo l’applicazione richiede una risoluzione di 1024x768 o simili, che vogliono appunto dire che se hai risoluzione maggiore la vedi piccola, mentre se vai in 800x600 ti occupa più dello spazio visibile... non sarebbe meglio invece vederla per tutta la larghezza disponibile, eventualmente più definita al crescere della risoluzione?
Concludo con un parallelo, sempre relativo a WPF, fra Resolution Independence e Time Independence: in WPF quando portate un’animazione da un PC lento ad uno molto veloce, questa non accelera: come è giusto che sia, semplicmente diventa più fluida. Anche questo argomento sarà oggetto di un prossimo post.
Riferimenti
- Matthew MacDonald: Pro WPF in C# 2008 - Introducing WPF, by Apress, capitolo in parte riportato qui
- Charles Petzold: Applications = Code + Markup - Capitolo 1, by Microsoft Press
- Adam Nathan: Windows Presentation Foundation Unleashed - Enter WPF, by SAMS
