!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> Quartz Extrême
  1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Mac OS X 10.2 : Jaguar (8)




Quartz Extrême

Quartz Extrême est le nom de la version accélérée par GPU de Quartz Compositor. Ce n'est pas un des efforts de marque les plus inspirés d'Apple, et beaucoup de fans de Mac ont entrepris de l'appeler d'une façon plus descriptive (et aussi moins embarrassante) du nom de Quartz GL. Je vais simplement l'appeler QE.

La couche d'affichage de Quartz a été abordée dans plusieurs articles précédents. Voici un résumé rapide pour vous rafraîchir la mémoire.


Quartz en un bref.

Quartz est un terme général qui décrit les technologies de base utilisées par Mac OS X pour afficher des images. Il comporte deux parties : Quartz 2D et Quartz Compositor.

Quartz 2D (appelé précédemment " Core Graphics Rendering") est une bibliothèque de tracé vectoriel d'images 2D. La description d'ensemble du système Mac OS décrit succinctement ses possibilités :

Les APIs [de Quartz 2D] vous permettent de créer du texte et des images en spécifiant une séquence de commandes et de traitements mathématiques qui disposent des lignes, des formes, des couleurs, l'ombrage, la transparence et d'autres attributs graphiques dans un espace 2D. Vous n'avez pas besoin de spécifier les attributs des pixels individuels. En conséquence, une forme peut être définie sans effort par une série de chemins et d'attributs plutôt que par un bitmap.

Quartz 2D accepte des entrées depuis des sources variées, et peut fournir des sorties sous différents formats, y compris PDF, PostScript, et bien sûr un bitmap adapté aux écrans d'affichage.

Quartz 2D a plusieurs APIs "jumelles" qui fournissent aussi des données en bitmap pour l'affichage sur écran : QuickDraw, QuickTime, et OpenGL. QuickDraw utilise en fait certaines APIs de Quartz 2D en arrière plan, mais QuickTime et OpenGL assurent leur propre tracé.

Toutes les données bitmap produites par Quartz 2D, QuickDraw, QuickTime et OpenGL sont transmises à Quartz Compositor pour un tracé effectif sur l'écran.

Quartz Compositor (précédemment appelé " Core Graphics Services") est conçu comme une seul processus "Window serveur" qui est responsable de la gestion de toutes les fenêtres sur l'écran. Chaque fenêtre a son bitmap associé (créé par l'application qui possède la fenêtre en utilisant une des APIs de dessin). Le serveur de fenêtres produit l'image finale sur l'écran en composant les uns avec les autres tous les bitmaps visibles de la fenêtre en fonction de leur position et de leur superposition. Tiré de la description d'ensemble du système :

[Le serveur de fenêtres] compose et recompose chaque pixel de la fenêtre d'une application à mesure que la fenêtre est dessinée, re-dessinée, recouverte, ou découverte. Chaque fenêtre est représentée par un bitmap qui inclut à la fois la transparence (canal alpha), et l'information d'anti-crénelage. Le bitmap sert de tampon, et permet au serveur de fenêtres de se "rappeler" du contenu de la fenêtre d'une application, et de le re-composer sans que l'application intervienne.

Le serveur de fenêtres véhicule aussi les évènements (par exemple les mouvements du curseur, les clics de souris, la frappe au clavier) vers les applications appropriées, et gère le curseur.

Donc, en un mot : les applications produisent des commandes de dessin en utilisant l'une des diverses APIs de dessin ; les APIs de tracé fournissent des bitmaps basés sur ces commandes de tracé (qui peuvent être vectorielles) ; le serveur de fenêtres retient les bitmaps résultants, et les compose en une image finale cohérente et agréable sur l'écran.


Les problèmes de performance.

Il y a au moins deux problèmes de performance avec une telle architecture. Comme nous l' avons vu dans les articles précédents, la quantité de mémoire utilisée pour conserver tous ces bitmaps de fenêtres devient rapidement importante. Pire, elle correspond de façon linéaire au nombre et à la taille des fenêtres sur l'écran.

Dans des architectures plus traditionnelles, les bitmaps ne sont pas conservés pour chaque fenêtre de l'écran. A la place, les applications sont sollicitées pour redessiner tout morceau nouvellement révélé de leurs fenêtres. Chaque application écrit dans un seul "tampon d'image" partagé, de la taille de l'écran lui-même (par exemple 1024 x 768 pixels). Ce tampon d'image est normalement stocké dans la mémoire vidéo de la carte graphique plutôt que dans la mémoire principale. Pour permettre un tracé plus régulier, on peut utiliser deux tampons d'image : l'un sur l'écran, et l'autre hors écran. Les applications dessinent sur le tampon d'image hors écran, et la carte vidéo alterne les deux tampons quand le tracé est terminé. De cette façon, on voit toujours le dessin "tel qu'il est".

Il est facile de calculer la mémoire vidéo requise pour l'affichage à une taille donnée en utilisant cette architecture plus traditionnelle. Deux tampons d'image de même taille et de même profondeur que l'écran lui-même (par exemple, 2 tampons de 1024 x 768 pixels x 32 bits = 50 331 648 bits soit 6 291 456 octets, 6 Mo).

Dans l'architecture de Mac OS X, la résolution de l'écran est presque sans effet sur l'utilisation de la mémoire. La mémoire des tampons d'affichage est insignifiante comparée au nombre potentiellement sans limites des fenêtres qui peuvent être sur l'écran à un moment donné, chacune ayant son propre tampon en bitmap, de la taille de la fenêtre.

Mac OS X stocke ses tampons de fenêtres dans la mémoire principale plutôt que d'essayer de les mettre tous dans la mémoire vidéo.Bien qu'aucun espace de mémoire ne soit sans limites, la mémoire principale est encore actuellement plus importante que la mémoire vidéo, et elle est gérée par le système de mémoire virtuelle de l'OS qui en vient à utiliser le disque quand la situation devient tendue. Quand cela arrive, la performance dégringole une falaise tout à fait abrupte.

Le second problème de performance est associé à la composition faite par le serveur. Plutôt que de simplement prendre les pixels de chaque bitmap de fenêtre, et de les afficher tels quels sur l'écran, le serveur de fenêtres doit mélanger chaque pixel avec ceux de toutes les autres fenêtres pour une même position de pixel, en prenant en compte la valeur de transparence de chaque pixel.

Quand la fenêtre est complètement opaque, les calculs sont beaucoup simplifiés. Mais chaque fenêtre de Mac OS X a son propre ombrage transparent, et sa barre de titre (si ce n'est pas la fenêtre la plus en avant). Les menus sont aussi en partie transparents, tout comme le Dock, les superpositions qui apparaissent quand vous actionnez le volume sonore ou la touche d'éjection des média sur le clavier, et ainsi de suite. En conséquence, la transparence est inévitable sous Mac OS X, et les calculs de composition deviennent d'autant plus importants que plus d'objets transparents apparaissent sur l'écran.


L'entrée en jeu de Quartz Extrême.

Alors, en quoi Quartz Extrême intervient-il ? Comme je l'ai dit précédemment, QE est la ré-implémentation de Quartz Compositor un utilisant QuartzGL, une définition qui doit vous dire quelque chose. Laissez-moi reprendre mon résumé "en un mot" du système graphique de Mac OS X sur l'écran, cette fois en prenant en compte Quartz Extrême. Restez avec moi, parce que, c'est un peu bizarre.

Les applications lancent leurs commandes de tracé en utilisant l'une des diverses APIs disponibles ; les APIs de tracé produisent des bitmaps à partir de ces commandes de tracé (éventuellement vectorielles) ; le serveur de fenêtres, maintenant dans l'application OpenGL, conserve les bitmaps résultants comme des textures dans des polygones dans la scène OpenGL, et les compose en une image cohérente et satisfaisante sur l'écran, en lançant des commandes OpenGL.

C'est un peu troublant d'imaginer le serveur de fenêtres comme une application OpenGL, mais c'est exactement cela. Simplement, c'est la seule application OpenGL qui n'envoie pas sa sortie au serveur de fenêtre pour la composition, parce que, eh bien, c'est le serveur de fenêtres lui même.

Voyons ce que cela nous donne en termes de performance. Voici une comparaison de l'architecture d'affichage avec, et sans Quartz Extrême.

figure

Sans Quartz Extrême.

figure

Avec Quartz Extrême

Voyez la multiplication soudaine des lignes rouges symbolisant le matériel dans le diagramme avec QE. Cela cherche à montrer que les calculs nécessaires pour composer les fenêtres des applications sont maintenant faits par le GPU de la carte graphique plutôt que par le processeur principal. Chaque fenêtre est traitée comme une surface OpenGL, et le bitmap du contenu de la fenêtre est une "texture" appliquée à cette surface.

Le résultat, en fin de compte, c'est que les cycles CPU préalablement utilisés à composer les fenêtres sont maintenant disponibles pour d'autres usages et que le GPU, auparavant largement inoccupé est mis à contribution pour ce qu'il sait faire de mieux.

Voyons maintenant ce que QE ne fait pas. D'abord, il n'affecte pas Quartz 2D, ni aucune autre API de tracé. Celles-ci continuent de fonctionner comme elles l'ont toujours fait, avec une participation égale du CPU.

Ensuite, QE ne diminue pas les besoins en mémoire de l'architecture d'affichage de Mac OS X. Le serveur de fenêtres doit encore conserver ses tampons bitmap pour chaque fenêtre sur l'écran et ces tampons sont encore stockés dans la mémoire principale pour les raisons exposées précédemment.

Pour une performance maximum, les textures (des tampons de mémoire) qui sont composées doivent résider dans la mémoire vidéo. Mais elles doivent aussi rester en mémoire principale, parce qu'elles peuvent être éliminée de la mémoire vidéo disponible à tout moment.

Sans QE, les données passent des tampons des fenêtres en mémoire principale jusqu'au CPU pour la composition. Avec QE, elles transitent de la mémoire principale à la mémoire vidéo. Cela réduit la surcharge du bus entre la mémoire principale et le CPU. Mais si tous les tampons de fenêtres ne peuvent pas tenir dans la mémoire vidéo, il y aura une forte charge du bus entre la mémoire principale et la carte vidéo.

Il n'est pas surprenant que les deux exigences pour supporter Quart Extrême soient au moins 16 Mo de VRAM (32 Mo recommandés), et un bus AGP2x (4x ou plus recommandé). En outre, comme les fenêtres sont de forme et de tailles très différentes, les cartes vidéo qui ne supportent pas des tailles de texture quelconques (par exemple l'ATI Rage 128) ne peuvent pas utiliser Quartz Extrême. La carte vidéo doit aussi supporter tous les formats de pixels utilisés par Quartz, et accepter les multi-textures.

Mon G3/400, avec sa carte Rage 128 et son bus PCI ne satisfait pas ces exigences, et ne peut donc pas utiliser Quartz Extrême. En revanche, la carte GeForce 4 MX de 64 Mo dans le connecteur AGP 4x de mon G4/800 est prête pour la chose. Nous verrons quelle différence cela fait dans la section suivante.