materiel

Test du MacBook Pro Retina 15" mi-2012 Core i7 à 2,3 GHz

par Anthony Nelzin le 26.06.2012 à 17:00
Écran Retina : 2880 x 1800 pixels… en théorie
Mais bien sûr, la star de ce MacBook Pro Retina, c'est précisément l'écran Retina. Pour bien comprendre comment il fonctionne, il faut remonter à 2005 et Mac OS X Tiger. À l'époque, les écrans n'ont quasiment pas évolué depuis vingt ans et toutes les applications sont adaptées à des écrans d'une résolution de 80 à 120 ppp. Mais alors que l'on commence à parler d'écrans de 200, voire 300 ppp, certains se posent des questions. En effet, à dimensions constantes, plus la résolution augmente, plus les pixels sont petits ; les interfaces étant le plus souvent construites de pixels, l'augmentation de la résolution signifie une réduction de leur taille, jusqu'à les rendre difficilement lisibles et manipulables. Il faut donc trouver un moyen de bénéficier des avantages de la montée en résolution (disparition progressive du crénelage à mesure que les pixels rapetissent) tout en évitant les inconvénients (diminution de la taille des éléments d'interface).


Comme d'autres, Apple imagine un système permettant aux applications d'adapter la taille de leurs ressources selon la taille de l'écran : c'est le principe de l'indépendance de résolution, qui utilise non des pixels pour les coordonnées de l'écran, mais des points, avec un ratio entre les pixels et les points.

Un élément de 10x10 pixels sur un écran de 100 ppp (ratio 1:1) doit être tracé en 15x15 pixels sur un écran de 150 ppp (ratio 1.5:1), et en 20x20 pixels sur un écran de 200 ppp (ratio 2:1) pour conserver la même taille : non seulement sa lisibilité ne sera pas réduite, mais elle augmentera même puisqu'une même surface en points sera tracée avec plus de pixels, diminuant ainsi le crénelage et augmentant la clarté. Mac OS X 10.4 Tiger inclut ainsi un nouveau débogueur Quartz qui facilite la tâche aux développeurs : ceux-ci peuvent simuler diverses résolutions d'écran et ainsi vérifier le comportement de leurs applications. La plupart des API système, notamment celle traçant le texte, s'adaptent automatiquement, seules les ressources bitmap posant problème.


En 2007, Coda gagne un Apple Design Award en partie parce qu'elle prend parfaitement en charge la mise à l'échelle et est donc indépendante de la résolution de l'écran — Mac OS X 10.5 Leopard intègre d'ailleurs un mode HiDPI. Deux ans plus tard, Mac OS X 10.6 Snow Leopard fait pourtant un pas en arrière : les coefficients libres de mise à l'échelle disparaissent — OS X Lion ne prend d'ailleurs en charge qu'un seul coefficient, le doublement dans chaque dimension.

Entretemps, iOS est passé par là. L'iPhone 4 a conservé la même taille d'écran que l'iPhone 3GS, mais sa résolution a doublé, passant de 163 ppp à 326 ppp. Cela signifie qu'il possède quatre fois plus de pixels : en théorie donc, il aurait pu afficher quatre fois plus d'éléments à l'écran, mais des éléments beaucoup plus petits. En pratique pourtant, les éléments des applications prennent exactement la même place sur l'écran : au lieu qu'un point soit constitué d'un pixel (1:1), il est constitué de deux pixels horizontaux et deux pixels verticaux (2:1 ou mode @2x). Les éléments semblent ainsi quatre fois plus définis.

Avec le Retina (à droite), les éléments sont tracés avec quatre fois plus de pixels en mode @2x. Dans notre exemple, les coins arrondis sont ainsi moins crénelés.

Avec cette approche, Apple a privilégié la lisibilité au détriment de la « surface » utilisable. Elle facilite aussi le travail des développeurs : au lieu de leur demander de travailler à des interfaces vraiment indépendantes de la résolution via des éléments vectoriels et une mise à l'échelle avec des coefficients qui ne sont pas toujours entiers, elle leur a simplement demandé de doubler les dimensions de leurs ressources bitmap, le système prenant la charge du reste.

Apple a procédé de même avec le MacBook Pro Retina : en théorie, un écran 15" de 1920 x 1080 pixels aurait suffit pour répondre à la définition d'un écran Retina — mais le coefficient de mise à l'échelle aurait alors été de 4/3, qui n'est pas un nombre entier, mais un nombre rationnel, et aurait donc requis un travail complexe de mise à l'échelle. Le plus simple était donc de doubler la résolution, comme avec l'iPhone ou l'iPad, et d'utiliser les pixels supplémentaires pour tracer les éléments de manière plus fine.


Ainsi, l'écran du MacBook Pro Retina compte bien 5,2 millions de pixels avec une définition horizontale de 2880 pixels et une définition verticale de 1800 pixels. Mais vous aurez compris que sa définition utile n'est pas de 2880x1800 pixels, car tous les éléments auraient alors été bien trop petits — d'ailleurs, si cette option est activable, elle n'est pas accessible en interface graphique.

Non, sa définition utile et nominale est toujours de 1400x900, mais il s'agit ici en fait de points composés de quatre pixels. Tous les éléments sont désormais tracés avec quatre fois plus de pixels, comme sur iOS, et apparaissent donc beaucoup plus fins. Vous trouvez que cela est compliqué ? Ce n'est pas que la partie immergée de l'iceberg, et le fonctionnement de l'écran Retina est en fait encore plus subtil.


Si vous ouvrez les préférences Moniteur du MacBook Pro Retina, vous constatez que par défaut, le mode Retina est activé : c'est le mode @2x ou ratio 2:1, ou échelle 2.0, selon le vocable employé. Dans ce mode, l'affichage est généré à une définition de 2880x1800 pixels, puis mis à l'échelle pour s'afficher sur l'écran à 1440x900 : le coefficient de mise à l'échelle et correspondance entre points et pixels étant un entier, le rendu est assez léger et permet cette grande finesse dans l'affichage.

Cette approche a des avantages : tous les éléments d'interface standards, les éléments vectoriels et les rendus graphiques et textuels utilisant les API d'OS X apparaissent ainsi à la « résolution Retina » et sont parfaitement nets. Elle a aussi des inconvénients : tous les éléments non-standard utilisant leur propre moteur de rendu doivent être adaptés, et apparaissent pour le moment sérieusement flous. Les ressources bitmap trop petites sont aussi upscalées avec une interpolation linéaire.

À l'avant-plan, Safari, qui rend le texte en mode Retina. À l'arrière-plan, Chrome, qui n'est pas encore adapté. La comparaison est cruelle.

Les choses deviennent amusantes lorsqu'on se rend compte que la mise à l'échelle ne se fait pas au niveau de l'écran, mais élément par élément. Ainsi dans Aperture ou Final Cut Pro X, deux applications compatibles avec le mode Retina, l'interface est mise à l'échelle avec le coefficient 2:1, et apparaît parfaitement détaillée en 1440x900. Mais l'image et les vidéos, elles, ne sont pas mises à l'échelle et sont rendues avec un coefficient 1:1 : il n'y a donc pas d'interpolation, et vous affichez une vidéo en HD 1080p pixel par pixel en mode Retina, ou pouvez voir 3 ou 4 millions de pixels d'une image.

Dès lors, si vous passez Aperture en plein écran, vous ne voyez pas une zone de 1400x900 d'une image dont les pixels auraient été interpolés, mais bien 2880x1800 d'une image au pixel près. On obtient ainsi le meilleur des deux mondes : OS X utilise quatre pixels pour tracer un point d'interface afin qu'il soit le plus défini possible, mais un pixel extrêmement fin pour tracer un pixel d'image ou de vidéo afin qu'elles soient les plus définies possibles. De ce point de vue, la gestion logicielle de l'écran Retina est une réussite incontestable.

L'interface d'Aperture est rendue en 2:1 (quatre pixels pour tracer un point), l'image est rendue en 1:1 (un pixel pour tracer un pixel). Les pixels de l'écran Retina étant très fins, le rendu de l'image est superbe.

Si vous arrivez toujours à suivre à ce degré de subtilité, vous vous demanderez sans doute comment sont générées les autres définitions accessibles dans les Préférences système. Les définitions supérieures équivalent à des définitions de 1680x1050 (celle du MacBook Pro 15" avec option HD) et 1920x1200 (la définition horizontale du MacBook Pro 17" avec option HD). Elles sont en fait d'abord rendues à respectivement 3360x2100 et 3840x2400, mises à l'échelle avec un coefficient de 2:1, puis conformées à l'écran 2880x1800.

On obtient donc une définition utile de 1680x1050 ou 1920x1200, avec l'apparence d'un système à 1680x1050 ou 1920x1200, tout en gardant une grande définition des éléments d'interface puisque la mise à l'échelle reste limitée. Ces définitions sont un peu moins fines que le mode Retina natif, mais incomparablement plus fines que les définitions équivalentes sur un MacBook Pro 15" ou 17" avec l'option HD, les pixels de l'écran Retina étant bien plus petits.

Le bureau en 1440 (cliquez pour agrandir).

Le même en 1680 (cliquez pour agrandir). C'est le mode dans lequel nous avons passé le plus de temps : il est extrêmement clair, mais offre un peu plus d'espace que le mode natif. Il correspond à la définition d'un MacBook Pro 15" HD, avec l'avantage de la résolution en plus.

Puis en 1920 (cliquez pour agrandir).

Enfin en 2880. Ce mode ne peut pas être activé avec l'interface graphique, mais peut l'être avec la ligne de commande. Une manière simple de le faire est d'utiliser l'utilitaire SetRes.

Cerise sur le gâteau : dans ces modes, OS X sait toujours mettre à différentes échelles différents contenus. Ainsi, en 1920x1200, Aperture est tracé en 3360x2100 avec des éléments mis à l'échelle pour qu'ils ne soient pas miniatures. Mais l'image, elle, n'est pas mise à l'échelle : si vous passez en plein écran, vous pourrez utiliser les 5,1 millions de pixels de l'écran Retina, et si votre image est plus petite, elle devra être interpolée.

Dans Final Cut Pro X, vous mettrez ainsi à l'écran plusieurs vidéos en HD 1080p côte à côte, sans interpolation, avec un rendu au pixel. Là encore, le fonctionnement de l'écran Retina est tout simplement redoutable : le casse-tête de l'indépendance de résolution est aujourd'hui résolu, et d'une manière d'ailleurs plus complète et complexe que sur iOS — bref, d'une manière adaptée aux besoins d'OS X.

<< Lire la page précédente (2/6)
Lire la page suivante (4/6) >>