Une petite info est en train de faire le tour de la toile des développeurs Windows Phone ce matin et je ne peux m’empêcher de la relayer, car la question sort assez souvent: il s’agit d’un feature documenté (j’insiste sur l’importance de chacun de ces deux mots) qui permet de passer le codage des couleurs de 16 à 32 bits quand une application en a besoin. Sans plus attendre, le truc:

<App xmlns="" BitsPerPixel="32" ...>

 

Dans le fichier WMAppManifest.xml de l’application (là ou il y a les capabilities, la définition des background agents etc) il y a une propriété BitsPerPixel de la balise App qui peut prendre les valeurs 16 ou 32 !

Cette fonctionnalité est documentée sur la page de doc qui concerne le manifest de l’application sur MSDN et est disponible uniquement dans Mango (Windows Phone 7.5).

Impacts? plus de “bandes” sur les gros aplats/dégradés de couleurs dans les photos et dans l’application (même si l’utilisation des dégradés est rarement “metro compliant”). Ca peut servir dans certains cas comme les jeux ou les applications à fort caractère graphique. La majorité ne devrait pas en avoir besoin… Et sachez que la différence est largement plus visible sur les écrans AMOLED que Super-LCD…

N’importe quel ingénieur en architecture de microprocesseur vous dira que le passage en 32 bits charge la mémoire, la mémoire graphique, le CPU, le bus du contrôleur vidéo. Ca va donc logiquement impacter la batterie et les performances du téléphone (CPU, mémoire, potentiellement framerate…). Est-ce que l’impact est visible à vous de me le dire, ça dépend du cas d’usage… Quant à la question “pourquoi on est pas en 32 bits par défaut?” la réponse la plus sensée qui me vient en tête (mais je ne suis pas dans le groupe produit…) c’est “parce qu’on en a pas besoin! (merci Metro!)”