John Siracusa

Quartz GL

J'ai pris plusieurs pages, dans mon compte-rendu de Tiger, à explorer comment dans Mac OS X la couche d'affichage Quartz avait évolué dans le temps, et notamment comment les fonctionnalités ont migré depuis le CPU et la mémoire principale vers le GPU et la VRAM. Tiger a apporté la dernière marche à cette évolution, Quartz 2D Extrême qui a fini par déplacer l'exécution des commandes de dessin elles-mêmes vers le GPU, en écrivant le résultat directement dans la VRAM.

J'ai consacré tellement de temps (et tant de graphes plaisants OmniGraffle) à Quartz 2D Extrême parce que c'était l'une des technologies de Tiger qui m'intéressait le plus. Je l'avais attendue longtemps, en bûchant dur depuis Mac OS 10.0, où tout dessin ou processus de composition se faisait sur mon pauvre CPU G3 à 400 MHz, dans l'attente qu'un jour, cela se ferait sur du matériel spécifique.

D'une façon regrettable, bien que le code de Quartz 2D extrême ait été inclus dans Tiger, il était invalidé par défaut. A l'époque, je supputais qu'il pourrait être validé dans une mise à jour ultérieure "peut-être aussi tôt que la version 10.4.1". Ah... Deux ans après, Tiger a atteint la version 10.4.11, et Quartz 2D Extrême est toujours invalidé par défaut.

Mais sûrement -sûrement- Quartz 2D extrême va être validé dans le puissant Léopard, non ? Quand il est question de déplacer le code vers le GPU, peut-être que nous devrions tous être habitués à la déception.

Les premières choses d'abord. Quartz 2D Extrême, qui vous remplissait presque la bouche, a été renommé Quartz GL dans Léopard. Je suis chaudement partisan de l'éviscération de "Extrême" dans tous les noms de produits Apple, alors oui. Deuxièmement, il est important de comprendre pourquoi Quartz GL fut invalidé dans Tiger pendant toutes ces années. Apple n'a jamais fait aucune déclaration publique à ce propos, mais les développeurs qui ont demandé ont reçu un message tout à fait cohérent. Et qui se ramène à des différences entre Quartz GL et les implémentations de Quartz plus anciennes, plus centrées sur le CPU, différences qui affectent effectivement des applications existantes.

Les bogues sont le problème évident. Quartz GL était un nouveau produit dans 10.4.0, une version qui avait bien assez de ses propres problèmes, sans vouloir ajouter un nouveau moteur de dessin à toutes ses applications. L'autre défaut important fut abordé dans le compte-rendu sur Tiger : Quartz GL peut effectivement rendre quelques applications plus lentes parce que les "meilleures pratiques" quand on écrit pour une implantation de Quartz centrée CPU/RAM sont exactement l'opposé de celles à utiliser pour Quartz GL.

Alors qu'est-ce qui a changé dans Léopard ? Vraisemblablement, la plupart des bogues de Quartz GL ont été éliminées, mais les problèmes de performance supposent que les développeurs d'applications changent leur code. Mais, pourquoi seraient-ils motivés à changer leur code ? Après tout, Quartz GL est invalidé dans Tiger. Cette situation de la poule et de l'œuf explique explique pourquoi Quartz GL n'est pas non plus validé globalement dans Léopard.

A la différence de Tiger, cependant, les applications de Léopard peuvent explicitement valider Quartz GL, soit pour toute l'application, soit seulement pour des fenêtres spécifiques. Cela autorise chaque développeur à choisir quand et où il utilise Quarz GL. Quarz GL, comme beaucoup de technologies de Léopard, va sûrement commencer à se répandre dans les applications qu'on utilise tous les jours. Cela n'est peut-être pas aussi évident que pour Core Animation, mais à long terme, c'est tout aussi important.

L'indépendance vis à vis de la résolution

Si on parle de technologies présentes dans Tiger, mais jamais validées, l'indépendance à la résolution fait quelques pas supplémentaires dans Léopard. Un simple rappel : dit simplement, l'indépendance à la résolution, parfois appelée "mise à l'échelle de l'interface utilisateur" ou "support pour des hautes résolutions d'image" (High DPI support) est la possibilité de dessiner les éléments de l'interface utilisateur en utilisant plus de pixels.

Par exemple, le petit widget rouge de fermeture dans la barre de titre d'une fenêtre utilise 16 x 16 pixels au facteur d'échelle par défaut (1.0). C'est bon pour les écrans qui ont autour de 100 pixels par inch (PPI), mais sur un écran avec 200 pixels par inch, cela donne une cible très petite pour cliquer dessus. En utilisant un facteur d'échelle de 2, le même widget serait dessiné en utilisant 32 x 32 pixels -quatre fois plus. Cela fait une cible à cliquer de même taille que celle de 16 x 16 pixels à l'échelle 1 sur un écran de 100 PPI. Le facteur d'échelle 2 pourrait aussi être plus détaillé, puisqu'il contient plus de pixels.

Cœurs inutilisés

Echelle 1 (à gauche), échelle 2 (à droite)

Les bénéfices de l'indépendance à la résolution sont doubles. Dans le haut de gamme, les écrans avec une densité de pixels plus grande deviennent utilisables, maintenant qu'il y a un moyen d'empêcher les widgets qui constituent l'interface graphique de se rapetisser jusqu'à devenir incliquables. En particulier, du texte apparaîtra bien plus net à mesure que le taux de PPI des écrans commencera à se rapprocher de celui des imprimantes modernes.

Dans le bas de gamme, l'indépendance à la résolution permet à des utilisateurs avec une mauvaise vision de rendre tout plus grand sur leurs écrans à faible PPI, en augmentant réellement la quantité de détails (par opposition au zoom d'écran courant qui ne fait qu'agrandir les pixels existants en rajoutant un flou gênant).

Sous Tiger, le facteur d'échelle de l'interface utilisateur n'existait que dans l'application Quartz Debug (une partie des outils de développement gratuits d'Apple). Et sous Léopard, le contrôle du facteur d'échelle pour l'interface utilisateur ... n'existe que dans l'application Quartz Debug. Désolé !

Augmenter effectivement le facteur d'échelle fournit une démonstration tout à fait convaincante de la raison pour laquelle il en est ainsi. Regardez les espaces non uniformes sur les contrôles segmentés dans cette recopie d'écran de Text Edit au facteur d'échelle de 2.0

Text Edit à l'échelle 2

Texte Edit au facteur d'échelle 2 : espacement irrégulier des contrôles segmentés

Comme vous pouvez le constater, il y a encore plein de défauts, même dans les applications les plus simples. Comme le facteur d'échelle a un effet global, il ne peut pas être validé partiellement comme avec Quartz GL.

A l'opposé de Quartz GL, Apple a effectivement tenu un message clair auprès des développeurs au sujet de l'indépendance à la résolution. Il y a eu des sessions aux dernières WWDC sur la façon de préparer les applicationsà fonctionner à des facteurs d'échelle supérieurs à 1.0. Le gros problème, c'est Apple elle-même qui n'a pas d'indépendance à la résolution fonctionnant correctement sur tous les frameworks graphiques de Mac OS X. De plus, les détails de la façon dont l'indépendance à la résolution intér-agissent avec les APIs ont changé à la WWDC 2007.

Néanmoins, la date qui se murmure pour l'apparition de l'indépendance à la résolution en tant que caractéristique visible par l'utilisateur dans Léopard est 2008. Le début de 2008 ? La fin de 2008 ? Si Apple le sait, elle ne dit rien. Si bien que la question posée il y a deux ans est toujours pendante. Qu'est-ce qui viendra le premier, des moniteurs de prix abordable à PPI élevé, ou une version indépendante à la résolution de Mac OS X ? L'attente se prolonge.

Mais ce n'est pas tout ce qu'il y a à dire à propos de l'indépendance à la résolution. En fait, on pourrait dire il y a encore une chose...