Concernant les « couches » qui ces derniers années ont alourdi/ralenti le rendu des polices, il faut préciser qu'il s'agit surtout de l' "unicodisation" globle des DE
Je ne suis pas sûr que ce soit le point le plus important dans la complexité du rendu des polices. À mon avis, le rendu graphique des caractères est la partie lourde du traitement :
Il y a quelques années n'existaient que les polices "bitmap" : chaque caractère dans la police est représenté par une image d'un taille et d'une résolution fixées par avance. C'est super rapide à afficher à l'écran. Par contre, c'est très peu flexible, car on ne peut utiliser que les tailles dont on dispose réellement. Regardez par exemple dans /usr/X11/lib/X11/fonts (avec des variantes selon les distributions). Vous allez normalement trouver entre autres deux répertoires intitulés '100dpi' et '75dpi', contenant ces polices bitmap. Par exemple, j'ai :
C'est donc une police Courier, disponible en 100dpi et 75 dpi, et dans les tailles 1,2,3,4,9,10,13,14,15 et c'est tout.
Ce genre de polices est utilisé dans les terminaux Linux (tty), ou encore dans Xterm.
À côté de ça, on a des polices vectorielles, dont les "TrueType", "Type1", ou encore "OpenType". Ici, chaque caractère est enregistré sous formes vectorielle, donc peut être utilisé théoriquement pour n'importe quelle taille avec une "simple" mise à l'échelle. C'est très bien pour les imprimantes qui disposent d'une très bonne résolution, mais c'est beaucoup plus délicat quand on considère le rendu sur écran avec nos chers pixels.
Pour avoir quelque chose de correct, on ajoute de l' "antialiasing", ou lissage, qui consiste à utiliser des dégradés de couleurs au lieu de transitions brutes de la couleur de fond vers la couleur du caractère. Au départ, cet antialiasing était aussi relativement simple : un caractère en noir serait représenté avec des légers dégradés de gris. Mais, on peut faire mieux avec le 'subpixel antialiasing' : cette fois, le dégradé peut utiliser d'autres couleurs si nécessaire. C'est ce que Microsoft appelle le lissage "ClearType" sous Windows. Sous KDE, c'est traduit par "halo de sous-pixellisation".
Enfin, il est utile d'utiliser une étape de 'hinting' qui consiste à déformer légèrement le caractère pour que les lignes verticales et horizontales soient alignées sur les pixels de l'écran. Ceci rend le caractère plus net.
Pour expliquer cela, voici quelques copies d'écran grossies 3 fois :
Qui voudrait abandonner l'antialiasing et le hinting après avoir vu ça, hein ?
Toutes ces opération nécessitent d'analyser le dessin du caractère, et ça prend du temps, beaucoup de temps ! En tenant compte du nombre de caractères actuellement affichés dans ce commentaire, vous comprendrez que votre CPU a du bien travailler ! (eh oui, je dis bien CPU, parce que le 'subpixel antialiasing' n'est actuellement accéléré par aucune carte graphique à ma connaissance.)
Ajoutons à ça que de plus en plus de choses en dehors des polices de caractères sont "antialiasées" dans nos bureaux aujourd'hui. La librairie graphique Cairo en est l'exemple par excellence. Elle intègre maintenant gtk+2 et améliore considérablement le rendu de certains widgets comme le sélecteur de couleur. Les moteurs de thème l'utiliseront bientôt (gtk-engines 2.7 a été réécrit sur Cairo). Firefox 2 devrait utiliser Cairo également (ceci dit Firefox doit déjà profiter de l'antialiasing dans une certaine mesure avec son moteur actuel). Un dernier exemple de ces techniques d'antialiasing et de 'hinting' appliqué au tracé de graphes scientifiques : j'ai récemment écrit un nouveau terminal interactif et multiplateforme grâce à Cairo (ce que je n'aurais jamais pu faire sans cette "couche supplémentaire") pour gnuplot. Comparez vous-même le rendu sous ce nouveau terminal avec le terminal X11 original :
Encore une fois, qui voudrait retourner en arrière maintenant qu'on a ces librairies puissantes et faciles d'utilisation, même si la responsivité en a pâti un peu ? Nul doute que des optimisations comme le travail de Federico Mena-Quintero ( http://primates.ximian.com/~federico/news.html ) viendront améliorer tout ça.
P.S. : En plus, certaines algorithmes associés aux polices TrueType et destinés à faciliter ce traitement sous soumis à un brevet [1] , ce qui fait que la librairie FreeType [2] utilise dans la plupart des distributions une implémentation alternative, mais sub-optimale.
[^] # Re: Ce qui est dommage
Posté par tipote . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 10.
Je ne suis pas sûr que ce soit le point le plus important dans la complexité du rendu des polices. À mon avis, le rendu graphique des caractères est la partie lourde du traitement :
Il y a quelques années n'existaient que les polices "bitmap" : chaque caractère dans la police est représenté par une image d'un taille et d'une résolution fixées par avance. C'est super rapide à afficher à l'écran. Par contre, c'est très peu flexible, car on ne peut utiliser que les tailles dont on dispose réellement. Regardez par exemple dans /usr/X11/lib/X11/fonts (avec des variantes selon les distributions). Vous allez normalement trouver entre autres deux répertoires intitulés '100dpi' et '75dpi', contenant ces polices bitmap. Par exemple, j'ai :
courB08-ISO8859-10.pcf.gz
courB08-ISO8859-13.pcf.gz
courB08-ISO8859-14.pcf.gz
courB08-ISO8859-15.pcf.gz
courB08-ISO8859-1.pcf.gz
courB08-ISO8859-2.pcf.gz
courB08-ISO8859-3.pcf.gz
courB08-ISO8859-4.pcf.gz
courB08-ISO8859-9.pcf.gz
courB08.pcf.gz
C'est donc une police Courier, disponible en 100dpi et 75 dpi, et dans les tailles 1,2,3,4,9,10,13,14,15 et c'est tout.
Ce genre de polices est utilisé dans les terminaux Linux (tty), ou encore dans Xterm.
À côté de ça, on a des polices vectorielles, dont les "TrueType", "Type1", ou encore "OpenType". Ici, chaque caractère est enregistré sous formes vectorielle, donc peut être utilisé théoriquement pour n'importe quelle taille avec une "simple" mise à l'échelle. C'est très bien pour les imprimantes qui disposent d'une très bonne résolution, mais c'est beaucoup plus délicat quand on considère le rendu sur écran avec nos chers pixels.
Pour avoir quelque chose de correct, on ajoute de l' "antialiasing", ou lissage, qui consiste à utiliser des dégradés de couleurs au lieu de transitions brutes de la couleur de fond vers la couleur du caractère. Au départ, cet antialiasing était aussi relativement simple : un caractère en noir serait représenté avec des légers dégradés de gris. Mais, on peut faire mieux avec le 'subpixel antialiasing' : cette fois, le dégradé peut utiliser d'autres couleurs si nécessaire. C'est ce que Microsoft appelle le lissage "ClearType" sous Windows. Sous KDE, c'est traduit par "halo de sous-pixellisation".
Enfin, il est utile d'utiliser une étape de 'hinting' qui consiste à déformer légèrement le caractère pour que les lignes verticales et horizontales soient alignées sur les pixels de l'écran. Ceci rend le caractère plus net.
Pour expliquer cela, voici quelques copies d'écran grossies 3 fois :
Pas d' "antialiasing", pas de "hinting" :
http://tipote.free.fr/lissage/images/rien.png
Avec "subpixel antialiasing", pas de "hinting" :
http://tipote.free.fr/lissage/images/subpixel.png
Avec "subpixel antialiasing" et "hinting" :
http://tipote.free.fr/lissage/images/subpixel_hinting.png
Qui voudrait abandonner l'antialiasing et le hinting après avoir vu ça, hein ?
Toutes ces opération nécessitent d'analyser le dessin du caractère, et ça prend du temps, beaucoup de temps ! En tenant compte du nombre de caractères actuellement affichés dans ce commentaire, vous comprendrez que votre CPU a du bien travailler ! (eh oui, je dis bien CPU, parce que le 'subpixel antialiasing' n'est actuellement accéléré par aucune carte graphique à ma connaissance.)
Ajoutons à ça que de plus en plus de choses en dehors des polices de caractères sont "antialiasées" dans nos bureaux aujourd'hui. La librairie graphique Cairo en est l'exemple par excellence. Elle intègre maintenant gtk+2 et améliore considérablement le rendu de certains widgets comme le sélecteur de couleur. Les moteurs de thème l'utiliseront bientôt (gtk-engines 2.7 a été réécrit sur Cairo). Firefox 2 devrait utiliser Cairo également (ceci dit Firefox doit déjà profiter de l'antialiasing dans une certaine mesure avec son moteur actuel). Un dernier exemple de ces techniques d'antialiasing et de 'hinting' appliqué au tracé de graphes scientifiques : j'ai récemment écrit un nouveau terminal interactif et multiplateforme grâce à Cairo (ce que je n'aurais jamais pu faire sans cette "couche supplémentaire") pour gnuplot. Comparez vous-même le rendu sous ce nouveau terminal avec le terminal X11 original :
http://tipote.free.fr/wxt19.png
Encore une fois, qui voudrait retourner en arrière maintenant qu'on a ces librairies puissantes et faciles d'utilisation, même si la responsivité en a pâti un peu ? Nul doute que des optimisations comme le travail de Federico Mena-Quintero ( http://primates.ximian.com/~federico/news.html ) viendront améliorer tout ça.
P.S. : En plus, certaines algorithmes associés aux polices TrueType et destinés à faciliter ce traitement sous soumis à un brevet [1] , ce qui fait que la librairie FreeType [2] utilise dans la plupart des distributions une implémentation alternative, mais sub-optimale.
[1] http://www.freetype.org/patents.html
[2] http://www.freetype.org