Tout simplement (c'est également expliqué dans l'article) parcequ'il y a moins d'aller/retour entre le client et le serveur, le client fait son choix/ sa résolution en local, son rendu et envoie en une seule fois les glyphs calculés 100% en local ou composés coté serveur avec Render.
On a donc:
- Dans tous les cas une latence moindre (c'est ce qui tue en général les perfs X)
- Dans certain cas un partage de la charge entre le client et le serveur, interressant sur du multiproc ou du client serveur multimachine.
- Si tu est chanceux aujourd'hui (en espérant que ca se généralise) tu profite de Render.
- Si tu est très chanceux, Render est en plus correctement accéléré par le driver de ta carte.
Le gain en perf des point 2,3 et 4 ne sont valables que si 1 est adressé sinon le gain en perf bien que réel en terme d'occupation CPU sera complètement imperceptible au chrono en regard de la latence.
L'avantage également des fontes coté client c'est contrairement aux "corefont" l'indépendance du protocole X vis à vis du format et des propriétés des fontes (quand on vois le bordel que ca a été et que c'est toujour plus ou moins avant d'avoir un support correct des fontes TT ou OpenType).
Un des arguments que répliquerons les détracteur des fontes coté clients à mon explication est que les points 3 et 4 peuvent très biens êtres appliqués aux fontes coté serveur.
Oui mais: au niveau perf c'est pas top, la négociation et le "roundtrip" global est énorme avec le protocole "corefont" -> "temp de latence qui pourri tout".
En plus, le protocole original de X pour gerer les fontes ne gère pas tous les nouveaux formats de fontes ni toutes les nouvelles caractéristiques de celles-ci.
Le choix fait est donc "d'aléger" le protocole en zappant complètement du protocole (et pas des API, ne pas tout confondre) la gestion des fontes (le fameux "corefont ) pour utiliser soit de la composition coté client soit coté serveur pour faire le rendu des fontes avec protocole X11 original ou protocole X11 original + render suivant les cas.
En ce qui concerne l'aspect "repositorie" centralisé pour les fontes, chose plutôt élégante et dispo de base avec le serveur de fonte untilisant le protocole "corefont" original:
Le fait de faire le rendu coté client ne remet pas en cause cette possibilité. La différence, c'est qu'il faut réinventer un nouveau protocole. XFS utilise directement le protocole X11. Ce dont on a besoin, c'est de partager des fichiers de fontes.
Aujourd'hui, celà peut être fait avec NSF ou tout autre système de fichier réseaux, demain celà pourra peut être être à l'aide de l'implémentation du support http/ftp/... ou "XFSv2" spécifique dans fontconfig (avec système de cache et tout le tralala) qui ne sait aujoud'hui utiliser que des fichiers locaux.
Voilà, en espérant que tu y verra un peu plus clair.
[^] # Re: Le retour de XFree86 4.3 dans Mandrake Linux 10.0 Release Candidate 1
Posté par efuste . En réponse à la dépêche Du rififi pour XFree. Évalué à 2.
On a donc:
- Dans tous les cas une latence moindre (c'est ce qui tue en général les perfs X)
- Dans certain cas un partage de la charge entre le client et le serveur, interressant sur du multiproc ou du client serveur multimachine.
- Si tu est chanceux aujourd'hui (en espérant que ca se généralise) tu profite de Render.
- Si tu est très chanceux, Render est en plus correctement accéléré par le driver de ta carte.
Le gain en perf des point 2,3 et 4 ne sont valables que si 1 est adressé sinon le gain en perf bien que réel en terme d'occupation CPU sera complètement imperceptible au chrono en regard de la latence.
L'avantage également des fontes coté client c'est contrairement aux "corefont" l'indépendance du protocole X vis à vis du format et des propriétés des fontes (quand on vois le bordel que ca a été et que c'est toujour plus ou moins avant d'avoir un support correct des fontes TT ou OpenType).
Un des arguments que répliquerons les détracteur des fontes coté clients à mon explication est que les points 3 et 4 peuvent très biens êtres appliqués aux fontes coté serveur.
Oui mais: au niveau perf c'est pas top, la négociation et le "roundtrip" global est énorme avec le protocole "corefont" -> "temp de latence qui pourri tout".
En plus, le protocole original de X pour gerer les fontes ne gère pas tous les nouveaux formats de fontes ni toutes les nouvelles caractéristiques de celles-ci.
Le choix fait est donc "d'aléger" le protocole en zappant complètement du protocole (et pas des API, ne pas tout confondre) la gestion des fontes (le fameux "corefont ) pour utiliser soit de la composition coté client soit coté serveur pour faire le rendu des fontes avec protocole X11 original ou protocole X11 original + render suivant les cas.
En ce qui concerne l'aspect "repositorie" centralisé pour les fontes, chose plutôt élégante et dispo de base avec le serveur de fonte untilisant le protocole "corefont" original:
Le fait de faire le rendu coté client ne remet pas en cause cette possibilité. La différence, c'est qu'il faut réinventer un nouveau protocole. XFS utilise directement le protocole X11. Ce dont on a besoin, c'est de partager des fichiers de fontes.
Aujourd'hui, celà peut être fait avec NSF ou tout autre système de fichier réseaux, demain celà pourra peut être être à l'aide de l'implémentation du support http/ftp/... ou "XFSv2" spécifique dans fontconfig (avec système de cache et tout le tralala) qui ne sait aujoud'hui utiliser que des fichiers locaux.
Voilà, en espérant que tu y verra un peu plus clair.