Quando in Windows Phone, e in generale in XAML, si fa riferimento ad un colore si utilizza la forma esadecimale o i nomi dei colori, con i quali si va ad indicare le componenti ARGB con valori che vanno da 0 a 255 per l'alpha (la trasparenza), il red, il green e il blue. Questo formato, di 32 bit, permette di utilizzare un ampio spazio di colori, di 2 alla 24 esima (la trasparenza non amplifica la gamma).
In realtà, ciò che si esprime non è detto che sia poi quello visualizzato sul display. Oltre alle differenze tecnologiche che influenzano contrasto e bilanciamenti, con la versione 7.0 di Windows Phone quello che viene visualizzato a video è una riduzione del valore, portato a 16 bit, al fine di ridurre i calcoli da effettuare e ottimizzare i consumi della batteria. Questo in molti casi non è un problema, perché difficilmente la qualità del display potrebbe far notare la differenza, se non comparandola, e i requisiti grafici di Metro non mettono in risalto limiti sulla gamma dei colori. Diminuendo infatti da 32 a 16 bit, con immagini o superfici da ampie gamme, come i gradienti, si possono sicuramente notare differenze sgradevoli; come già detto è raro dovere usare questo genere di immagini, perché non uniforme alle linee guida di Metro.
Per questo motivo anche in Windows Phone 7.5 il comportamento predefinito è sempre quello di lavorare a 16 bit, ma qualora l'applicazione o il gioco dovesse sentire la necessità di avere una gamma di colori completa, è possibile abilitare i 32 bit. Per farlo occorre intervenire sul file WMAppManifest.xml e in particolare sull'elemento App, ponendo l'attributo BitsPerPixel="32", come nell'esempio.
<Deployment xmlns="http://schemas.microsoft.com/windowsphone/2009/deployment" AppPlatformVersion="7.1"> <App BitsPerPixel="32" ...> <!-- altro -->
Non serve fare altro e rilanciando l'app si ottiene automaticamente i benefici dei 32 bit. Da notare che non tutti i device supportano questa profondità di colore, perciò potrebbe non sortire alcun effetto. E' poi importante sottolineare che i 32 bit, per evitare uno spreco inutile di risorse, andrebbero abilitati solo se si ottiene un evidente vantaggio in base al tipo di applicazione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Creare alias per tipi generici e tuple in C#
Creazione di plugin per Tailwind CSS: espandere le Funzionalità del Framework
Recuperare un elemento inserito nella cache del browser tramite API JavaScript
Utilizzare politiche di resiliency con Azure Container App
Creare form tipizzati con Angular
Supportare il sorting di dati tabellari in Blazor con QuickGrid
Creazione di componenti personalizzati in React.js con Tailwind CSS
Eseguire attività basate su eventi con Azure Container Jobs
Eseguire una query su SQL Azure tramite un workflow di GitHub
Assegnare un valore di default a un parametro di una lambda in C#
Evitare la script injection nelle GitHub Actions
Installare le Web App site extension tramite una pipeline di Azure DevOps
I più letti di oggi
- Utilizzare Docker Compose con Azure App Service
- Modernizzare le applicazioni WPF e Windows Forms con Blazor
- annunciato #netstandard 2.1. .NET Core lo supporterà a partire da #netcore3, così come le prossime versione di #xamarin, #mono e #unity.il supporto per #netfx 4.8, invece, non ci sarà. https://aspit.co/bq2
- Steel Style CheckBox per Silverlight 4.0
- Utilizzare QuickGrid di Blazor con Entity Framework