L’indépendance de la résolution
On nous promet depuis des années des systèmes d’exploitation capables de s’affranchir des limites des écrans et des formats « historiques » comme le 96 ppp de Windows et le 72 ppp de Mac OS X. Si l’indépendance de la résolution est un beau concept, elle reste un serpent de mer dans le monde des systèmes d’exploitation.
Actuellement, quand on augmente la définition de l’écran, on voit plus de choses à l’écran, mais on reste fondamentalement sur le même fonctionnement. Un écran en 1 280 x 800 et un écran en 2 560 x 1 600 affichent les mêmes données, elles sont simplement quatre fois plus petites sur le second. Et comme la taille physique de l’écran augmente généralement avec, les différences pratiques sont faibles. Si les écrans ne dépassent toujours pas 2 560 x 1 600 aujourd’hui (alors que les premiers modèles datent de 2004), c’est que les systèmes d’exploitation limitent.
Pourtant, les smartphones ont montré que des écrans plus « fins », offrant une image de meilleure qualité, avaient un intérêt. Que ce soit l’iPhone 4 d’Apple et son écran Retina ou les écrans en hautes définitions des smartphones Android, le gain est immédiat et particulièrement visible.
Dans ce dossier, nous allons montrer qu’il existe des solutions et expliquer pourquoi l’indépendance de la résolution n’est pas généralisée dans le monde des PC.
Définition, résolution, indépendance…
Quelques exemples de valeurs en ppp
Quelques exemples de valeurs de résolution. Un écran de 15 pouces en 1024 x 768 (les premiers écrans plats) travaille à 85 ppp. Un écran de 24 pouces en 1 920 X 1 080 (courant actuellement) atteint 94 ppp. Un écran de 27 pouces en 2 560 x 1 440 est à 108 ppp. Dans les portables, un 10 pouces en 1 024 x 600 (netbooks) est à 118 ppp. Un portable 17 pouces en 1 600 x 900 est à 108 ppp. Le cas des smartphones est un peu différent et nous allons en parler dans les pages suivantes.
Avant de commencer, expliquons bien les concepts de base.
Un moniteur est généralement caractérisé par deux choses : sa définition et sa diagonale. Le premier point, la définition, est ce qu’on appelle parfois (à tort) la résolution, c’est le nombre de pixels qu’il est capable d’afficher. On parle par exemple d’un écran en 1 920 X 1 080 ou d’un écran en 800 x 480. Les deux valeurs représentent le nombre de pixels en largeur et en hauteur et permettent de calculer le nombre de pixels de l’écran.
Le second point est un détail physique : sa diagonale. Exprimée généralement en pouces (1 pouce = 2,54 cm), elle permet de déterminer rapidement la taille des pixels : un écran de 55 pouces en 1 920 x 1 080 aura des pixels plus gros qu’un écran de 15 pouces en 1 920 x 1 080 (deux exemples réels).
La résolution est un mélange des deux valeurs. Rarement communiquée par les constructeurs, la résolution est exprimée en ppp (point par pouce) ou en dpi (dot per inch en anglais). Plus la valeur en ppp est élevée plus les pixels sont petits. Attention, les pixels ne sont pas nécessairement plus nombreux : la résolution est juste une indication sur la taille physique des pixels.
La dépendance de la résolution
Pour l’utilisateur, est-il important de connaître la résolution ? Oui et non. Dans la majorité des cas, non. Pour les gens qui travaillent beaucoup sur un ordinateur et ont des problèmes de vue, c’est important. Comme la résolution définit la taille des pixels, elle définit aussi directement la taille des éléments affichés à l’écran. Dans les systèmes classiques, les interfaces sont dépendantes de la résolution. Concrètement, un texte affiché sur un écran qui travaille à 160 ppp sera deux fois plus petit que sur un écran qui travaille à 80 ppp (rappelez-vous, la résolution est juste une indication de taille physique).
Pour une personne qui a des problèmes de vue, il est donc nécessaire de prendre des écrans avec une résolution faible, sous peine de ne pas arriver à lire les informations affichées à l’écran sans zoomer. On recommande en général de ne pas dépasser 110 ppp sur un écran d’ordinateur de bureau et la plupart des utilisateurs préfèrent rester aux alentours de 100 ppp. Il existe des écrans qui offrent une résolution plus élevée, mais la réaction habituelle du public est que les textes sont écrits trop petit. Sur un ordinateur portable, dont l’utilisateur est souvent plus proche, 120 ppp est une valeur optimale.
L’indépendance de la résolution
L’idée de l’indépendance de la résolution est de s’affranchir de ce paramètre, d’où son nom, en utilisant des interfaces qui ne dépendent pas de cette résolution. Dans un système d’exploitation classique, la taille des polices et des éléments d’interface est fixe et a été pensée pour une valeur de 96 ppp (Windows) ou 72 ppp (Mac OS X). Il faut bien comprendre ce que ça veut dire : la taille en pixels des éléments (pas la taille physique) est calculée en considérant que l’écran a une résolution de 96 ppp (ou 72 ppp), sans prendre en compte la valeur physique. Ce qui implique que la taille en pixels est fixe, quel que soit l’écran.
Donc si l’écran a une résolution plus faible, le texte sera plus gros que ce qui a été prévu, et si l’écran a une résolution plus élevée (cas le plus classique), le texte sera plus petit. Le fait que les utilisateurs préfèrent des écrans qui travaillent aux alentours de 100 ppp n’est pas un hasard : c’est la valeur de base du système le plus courant.
Avec l’indépendance de la résolution, le but est que les systèmes d’exploitation — et plus généralement les logiciels — s’adaptent à l’écran pour que les textes et autres éléments d’interface gardent la même taille relative et — si possible — améliore la qualité de l’image. En effet, si une lettre nécessite 10 pixels sur un écran et 20 pixels sur un autre, mais que la taille physique est la même, la seconde sera a priori plus nette et donc « de meilleure qualité ».
Pourquoi n’est-ce pas encore utilisé ?
Le concept d’indépendance de la résolution n’est pas nouveau, mais il pose plusieurs problèmes : le matériel et le logiciel.
Le matériel
Au niveau du matériel, il faut bien prendre en compte une chose : ça demande plus de ressources. Même si ce n’est pas totalement corrélé, travailler sur un écran en 200 ppp implique généralement qu’on travaille sur un écran qui a quatre fois plus de pixels que le même écran en 100 ppp. La raison est simple : éviter de perdre en espace de travail. Si une personne travaille sur un écran de 24 pouces en 1 920 x 1 080 (94 ppp), on ne va pas lui dire de passer sur un 12 pouces (dans la même définition) avec comme prétexte « c’est mieux ». Non, on va essayer de lui trouver un écran de 24 pouces en 3 840 x 2 160. Soit quatre fois plus de pixels. Et ce genre d’écrans, ce n’est pas la norme.
Donc même si l’interface est de la même taille relative, la carte graphique, elle, travaille bien avec plus de pixels. Sur une machine de 2011, qui possède une carte graphique puissante et souvent dotée de plusieurs Go de mémoire, ce n’est pas réellement un problème d’animer l’interface d’un système d’exploitation, même s’il y a quatre fois plus de travail. Mais sur un ordinateur d’entrée de gamme avec un IGP un peu ancien (un GMA 950 par exemple) et 64 Mo de mémoire partagée, ça peut poser un problème.
Travailler avec quatre fois plus de pixels implique une charge supplémentaire de calculs, une utilisation plus élevée de la mémoire vidéo et une charge supplémentaire sur le bus de la carte vidéo.
En dehors du côté performances, il y a aussi des problèmes plus simples : comment connecter un écran en très haute définition ? Le DVI et le HDMI limitent souvent à 1920 x 1200 dans la pratique (le Dual Link n’est ni généralisé ni pratique) et le DisplayPort n’est pas encore utilisé dans toutes les machines.
Le logiciel
Le plus gros problème vient au final du logiciel. En effet, l’indépendance de la résolution implique que les éléments de l’interface puissent être redimensionnés tout en restant visuellement propres. Si pour le texte ce n’est pas un réel problème étant donné que les polices de caractères sont majoritairement vectorielles, c’est plus gênant pour les éléments d’interfaces, les boutons, etc. Dans beaucoup de cas, il s’agit d’images bitmap qui supportent mal l’agrandissement. Une image nette quand elle mesure 20 pixels de haut ne le sera pas si on lui dit que maintenant elle doit mesurer 40 pixels de haut.
Pour le système d’exploitation, ce n’est pas un (trop) gros problème : les interfaces actuelles sont en grande partie vectorielles et il « suffit » de fournir des bitmap de grande taille quand c’est nécessaire : si l’agrandissement est problématique pour la qualité (sauf dans les Experts), la réduction est par contre bien maîtrisée. Une image de 20 pixels de hauteur agrandie à 40 pixels pose problème. Une image de 80 pixels de hauteur rétrécie à 40 pixels est par contre utilisable.
Le souci vient des applications tierces : elles ne sont pas toutes adaptables, les interfaces ne sont pas toujours vectorielles, redessiner tous les bitmaps n’est pas toujours possible, etc. De plus, il faut que les applications puissent se rendre compte que l’indépendance de la résolution est activée, ce qui n’est pas trivial.
Même si l’indépendance de la résolution était activée dès maintenant (les systèmes d’exploitation en sont capables), l’intérêt serait faible : le matériel n’est pas adapté et les logiciels ne le sont pas non plus.
LCD et problèmes d’indépendance de résolution
Si vous avez suivi les pages précédentes, vous avez remarqué que nous avons implicitement considéré que la résolution devait être doublée, alors que l’indépendance de la résolution devrait permettre, stricto sensu, de prendre n’importe quelle valeur. Il y a une bonne raison.
Les écrans LCD posent des problèmes
Quand les premiers travaux sur l’indépendance de la résolution ont commencé, la majorité des écrans étaient des modèles CRT. Et si ces derniers ont beaucoup de défauts par rapport à un écran LCD, ils gardent tout de même un avantage : ils peuvent afficher n’importe quelle définition. On peut afficher de façon native (avec tous les défauts de ce type d’écrans) une image en 640 x 480, une image en 1 024 x 768 ou une image en 1 600 x 1 200. Si on veut faire varier la résolution, c’est assez simple et l’image n’est pas dégradée : il est donc possible d’imaginer une « vraie » indépendance de la résolution.
Avec les écrans LCD, ce n’est pas vraiment possible. En effet, les pixels sont fixes et afficher une autre définition que la native implique un redimensionnement des images et une dégradation de la qualité. Typiquement, afficher une image en 1 366 x 768 sur un écran en 1 920 x 1 080 va en fait se résumer à calculer une image en 1 366 x 768 et à l’afficher en 1 920 x 1 080, en espérant que les pixels ne se chevauchent pas trop en dégradant l’image. Même si les algorithmes de redimensionnement sont efficaces, on a tout de même un effet de flou qui apparaît souvent.
La solution, déjà utilisée dans les smartphones (nous allons y revenir) est de travailler avec des multiplicateurs fixes. On n’a donc pas une véritable indépendance de la résolution, mais une solution intermédiaire, acceptable, qui va permettre d’utiliser les écrans en très haute définition sans rendre les interfaces inutilisables.
Un multiplicateur fixe
Il y a une solution simple : travailler avec des multiplicateurs fixes, généralement 2x. Affirmer qu’un écran LCD n’est totalement net que dans sa définition native est partiellement faux : il y a au moins un cas où l’image va rester nette. Si on divise la largeur et la hauteur par deux, chaque pixel va correspondre à quatre pixels réels et les problèmes de chevauchement ne vont pas se poser : l’image paraîtra grossière, mais sera nette. C’est très visible avec un écran 27 pouces en 2 560 x 1 440 : travailler en 720p (1 280 x 720) permet d’obtenir une image de bonne qualité.
L’intérêt est double : d’une part on évite les problèmes de redimensionnements et de flou et d’autre part on garde une compatibilité avec l’existant. Imaginons un écran de 24 pouces en 3 840 x 2 160. Sa résolution est de 188 ppp, ce qui est élevé. Avec un système d’exploitation adapté, on peut travailler en doublant la résolution de l’interface et l’écran se comporte comme un écran en 1 920 x 1080 : on gagne en finesse au niveau de l’interface. Avec un système d’exploitation qui n’accepte pas l’indépendance de la résolution, on peut travailler réellement en 1 920 x 1080 : il y a un redimensionnement, mais sans pertes visibles.
La solution du multiplicateur fixe n’est pas totalement indépendante de la résolution, mais permet de profiter des avantages au niveau de la qualité tout en gardant une rétrocompatibilité efficace, ce qui est toujours intéressant.
Le cas des smartphones : deux solutions
Parlons d’un cas précis où l’indépendance de la résolution est en partie utilisée : les smartphones. Et intéressons-nous à deux solutions : celle d’Android et celle d’iOS. Pour Windows Phone 7, il n’y a pas besoin de gérer le problème, tous les appareils travaillent avec la même définition et des écrans dont la diagonale est proche.
Le cas iOS
Commençons par le plus simple : iOS. Apple propose une gamme de téléphones restreinte, ce qui est un avantage dans ce cas précis. On trouve des modèles avec des écrans de 3,5 pouces en 480 x 320 (165 ppp), des modèles avec des écrans de 3,5 pouces en 960 x 640 (329 ppp) et des modèles avec des écrans de 9,7 pouces en 1 024 x 768 (142 ppp).
Pour les applications iPhone sur iPad, Apple a fait le choix de ne pas redimensionner les applications. Elles sont affichées en 1:1, c’est-à-dire qu’un pixel de l’iPad correspond à 1 pixel de l’application iPhone. Comme la résolution de l’iPad est moins élevée que celle de l’iPhone, l’image est plus grande, équivalente à un iPhone de 4 pouces environ. Il est aussi possible de travailler en 2:1 (4 pixels de l’iPad pour 1 pixel de l’application), mais le résultat est médiocre : il n’y a pas d’indépendance de la résolution.
Pour l’iPhone 4 et l’iPod touch 4G, Apple a mieux travaillé : il y a indépendance de la résolution. C’est un facteur fixe qui est utilisé : si l’application n’est pas pensée pour les appareils récents, quatre pixels de l’écran correspondent à un pixel de l’application. Comme la diagonale est identique et la définition doublée, le résultat est propre. Visuellement, une application classique lancée sur un iPhone ou un iPhone 4 est identique. L’indépendance de la résolution est intégrée dans le système d’exploitation et les éléments vectoriels (textes, barre de menu) sont tout de même rendus en 329 ppp, même si le reste de l’application n’est pas compatible.
Pour les développeurs, la seule contrainte est de proposer leurs bitmap en définition doublée dans les applications, le reste est géré par l’OS.
Le cas Android
Avec Android, c’est un peu plus compliqué, mais un peu plus souple. La raison est simple : comme il y a énormément d’appareils différents et que la diagonale de l’écran ainsi que sa définition varient, il est impossible de travailler avec un système à base de multiplicateurs fixes.
Pour régler le problème, Android propose deux solutions pour les développeurs. La première concerne les éléments d’interface et leur position : en fonction de la définition, il est possible de définir un positionnement différent et donc proposer une interface différente. Il existe quatre choix : small, normal, large et xlarge. Le format de base est normal, avec typiquement un écran en 480 x 320. Un programme adapté va donc détecter ou positionner correctement ses boutons sur un grand écran, par exemple.
La seconde solution, complémentaire, consiste à proposer des bitmaps adaptés pour les différentes résolutions. Il y a le mode ldpi (~120 ppp), mdpi (le standard, ~160 ppp), hdpi (~240 ppp) et xhdpi (~320 ppp). Tous ne sont pas obligatoires et si seul le mdpi est présent, il sera redimensionné en fonction de l’écran.
La valeur en ppp de l’écran, elle, n’est pas calculée directement, mais intégrée dans l’appareil par le constructeur (il est même possible de la modifier manuellement) : cela permet aux constructeurs de proposer des écrans haute définition en gardant des textes de taille correcte avec les applications qui ne prennent pas en compte ce type d’écran.
Techniquement, il n’y a pas totalement indépendance de la résolution, mais en pratique c’est invisible. Un utilisateur classique ne sera pas choqué si un texte est un peu plus petit sur un écran de 3 pouces que sur un écran de 4 pouces s’ils ont la même définition. Le seul moment où la solution d’Apple est meilleure c’est quand les applications ne prennent pas en charge l’indépendance de la résolution : les textes risquent d’être très petits et les bitmaps de mauvaise qualité sur un écran en haute définition. La version 3.2 d’Android devrait corriger ce problème en intégrant un mode « zoom » capable de redimensionner correctement les applications au prix du flou inhérent à ce type de solution.
Un exemple d’indépendance avec le HiDPI
Nous avons testé l’indépendance de la résolution avec deux systèmes : Mac OS X et Windows 7. Commençons par Mac OS X, qui propose — dans sa dernière version — un mode spécifique.
HiDPI
Le HiDPI est un mode activable dans les outils de développement qui reprend (basiquement) le fonctionnement du « Retina » de l’iPhone 4. L’idée est de travailler — si possible — avec un multiplicateur fixe, ici 2x. Concrètement, passer en HiDPI double la taille des éléments de l’interface, ce qui permet d’obtenir une finesse inhabituelle au niveau des caractères, par exemple. Apple devrait proposer assez rapidement des écrans compatibles : les fonds d’écran du système d’exploitation sont par exemple disponibles en 3 200 x 2 000, une définition qui n’est pas disponible sur des écrans grands publics. Et imaginer un ordinateur portable avec un écran en 3 200 x 2 000 en HiDPI (soit 1 600 x 1 000 en pratique) n’est pas irréaliste.
Concrètement ?
Concrètement, le HiDPI permet d’obtenir un résultat très efficace sur la majorité des applications, même s’il reste quelques éléments d’interface en bitmap qui supportent mal le redimensionnement. Le gros défaut actuellement, c’est que passer en mode HiDPI implique de diminuer la définition « utile ». Un écran en 1 920 x 1 200 (réel) devient donc un écran en 960 x 600 (simulé) en HiDPI. Le système trace les éléments dans la définition native avec un agrandissement d’un facteur 2, mais les applications voient un écran en 960 x 600, ce qui peut poser des problèmes. Le gain en qualité est intéressant, comme on le voit sur les captures, mais c’est inutilisable en pratique, la définition « utile » est trop faible.
Pour notre test, nous avons utilisé un écran de 30 pouces, qui a une définition native de 2 560 x 1 600. En HiDPI, il est considéré comme un écran en 1 280 x 800, ce qui est utilisable. Assez étonnamment, on ressent assez peu l’effet « gros pixels », tout simplement parce que le rendu est effectué en définition native, mais les caractères et les éléments d’interfaces sont évidemment imposants.
Des bugs
C’est pour le moment une option réservée aux développeurs et ça se voit : certaines applications s’affichent très mal, d’autres ont des éléments d’interface en bitmap qui acceptent mal le redimensionnement, etc. Même si le mode HiDPI est plus efficace que les anciennes tentatives d’indépendance de la résolution chez Apple (les outils sont présents depuis Mac OS X 10.4), ce n’est pas encore réellement utilisable au quotidien.
Au final, le HiDPI ne sera réellement intéressant que quand des écrans pensés pour la technologie seront disponibles.
Sous Windows 7
Sous Windows 7, c’est un peu différent. En effet, le système propose de régler la taille des polices (et dans les faits, des éléments d’interface) selon un pourcentage. Par défaut, le système propose 125 % et 150 %, mais il est possible de régler la valeur plus finement.
Dans la pratique
Dans la pratique, ça fonctionne assez bien si on se limite aux applications fournies, comme avec OS X. L’interface et les textes sont très nets, mais certaines applications n’apprécient que moyennement le redimensionnement, comme Skype dans notre exemple : les textes et l’interface sont flous. Les icônes de certains programmes sont aussi assez peu réussies : si le développeur ne propose pas une version en « haute définition », le rendu est assez peu flatteur. Dans d’autres applications, comme Firefox, le rendu est un peu étonnant : les textes sont très nets, très propres, mais les éléments d’interface ne sont visiblement pas vectoriels et l’agrandissement est très visible.
A l’oeil, le crénelage semble un rien plus présent que sous OS X une fois que les polices sont agrandies deux fois, mais ce n’est pas rédhibitoire.
Globalement, le rendu est plutôt bon tant qu’on reste dans des applications modernes, pour le reste, c’est un peu la loterie. Pour une personne qui a des problèmes de vue — la raison pour laquelle Microsoft propose cette option — c’est un compromis intéressant, dans les autres cas ce n’est pas assez abouti pour prendre en charge des écrans en très haute définition.
Conclusion
Alors qu’en penser ? Actuellement, l’indépendance de la résolution est encore loin de pouvoir arriver dans nos chaumières. Sans parler du côté technique — les écrans adaptés ne sont pas légion et sont très onéreux —, il reste encore beaucoup de bugs et la rétrocompatibilité est faible.
Pourtant, nous y croyons : même sur un 30 pouces en HiDPI, le résultat est impressionnant : la sensation de netteté est étonnante, le rendu est vraiment intéressant, quand ça fonctionne.
Les dernières versions des systèmes d’exploitation montrent que les développeurs y croient et même si nous allons devoir encore attendre quelques années avant que ce type de rendu se généralise, c’est une évolution très intéressante que nous attendons de pied ferme. C’est définitivement une technologie d’avenir, et nous espérons que cet avenir n’est pas trop lointain.
