Le talon d'Achille du lissage sous-pixel
Certaines personne sur la blogosphère anglophone se plaignent d’applications Mac OS X qui ne respectent pas leur préférence pour le lissage des polices sous-pixel. Pierre Igot pense que c’est de l’incompétence. Michael Tsai spécule qu’il y a peut-être un problème plus général qui fait que Quartz choisit parfois le lissage standard. John Gruber trouve tout simplement ça curieux. Et moi je sais exactement pourquoi ça arrive et pourquoi ce n’est pas facile à régler.
Michael Tsai penses que ce serait lié aux tampons hors-écran qui sont par la suite combinés ensemble :
Ce que je remarque c’est que des applications comme Pages et OmniGraffle dessinent plusieurs couches avec des éléments qui peuvent parfois passer les un sur les autres. Une façon logique d’implanter ceci est de dessiner les éléments séparément dans des tampons hors-écran et de les combiner ensemble par la suite.
Et il a tout à fait raison. Le problème c’est que sur ces tampons avec un fond transparent Quartz n’applique jamais de lissage sous-pixel. Et ce n’est pas de l’incompétence : il est tout simplement impossible de dessiner du lissage sous-pixel sur un fond transparent. Le problème s’appelle aRVB (ou aRGB en anglais), le voyez-vous ?
Voici l’explication.
Le lissage sous-pixel fonctionne en donnant différente valeurs aux trois sous-pixels à l’intérieur d’un pixel (rouge, vert, bleu) basé sur la distance de chacun de la courbe mathématique du glyphe de chaque caractère. Quand il dessine, chaque sous-pixel doit être appliqué avec un niveau de transparence différent.
Le “a” dans aRVB veux dire alpha — c’est la valeur de transparence pour le pixel au complet. C’est ça, pour tout le pixel : quand des pixels aRVB sont mélangés à d’autre couches, chaque sous-pixel est mélangé avec le même niveau de transparence. Ceci est incompatible avec le lissage sous-pixel qui nécessite un niveau de transparence différent pour chacun des trois sous-pixels.
Ceci dit, je penses que Quartz est plutôt intelligent parce que le lissage sous-pixel fonctionne quand même sur des fond semi-transparents, comme les menu que vous tirez de la barre des menus. Il implante une dégradation graduelle des sous-pixels. Par exemple, si le fond sur lequel il dessine du texte a une transparence de 50%, la moitié de la valeur de chaque sous-pixel sera du lissage standard, l’autre moitié étant du lissage sous-pixel.
Donc si une application dessine dans un tampon hors-écran avec un fond transparent — surprise ! — pas de lissage sous-pixel. Tant que Apple n’implantera pas une sorte de mode aRaGaB, les développeurs d’application devront choisir entre une application rapide avec des tampons hors-écran ou le lissage sous-pixel, mais pas les deux. Je pense que le choix est facile à faire pour les développeurs.
Notes
Un hypothétique mode aRaGaB ne pourrait pas bénéficier de l’accélération graphique de la carte vidéo (qui travaille en aRGB) ; une transparence sous-pixel ne serait probablement pas une amélioration suffisante pour justifier une composition des images plus lente et plus vorace en mémoire vive.
Le lissage sous-pixel ne fonctionne pas pour du texte ombré, probablement parce que Quartz à l’interne dessine le texte dans un tampon hors-écran pour pouvoir calculer l’ombre.
Vous pouvez tester et voir le lissage sous-pixel partiel pour les fond semi-transparents en jouant avec la transparence d’une fenêtre du terminal placé au dessus d’une autre fenêtre de la même couleur. Quand le fond devient totalement transparent, le lissage sous-pixel disparaît.
