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

Quartz




Quartz est le terme général pour le système d'affichage de Mac OS X, à travers lequel passe tout dessin ou tout affichage d'écran. Les parties les plus importantes de Quartz sont :

Quartz 2D. C'est une API de dessin vectoriel. Les fonctions qu'elle fournit s'associent gentiment aux commandes de dessin qui constituent le langage de description de page PDF de Adobe. Quartz en tire parti en permettant que à peu près tout ce qui est dessiné sur l'écran puisse être écrit dans un fichier PDF ; l'impression et l'affichage sur l'écran sont unifiés en une seule API.

Quartz Compositor. Un moteur qui combine (compose) les sorties numériques bit-map des commandes de dessin de chaque application en une seule scène.

Window Server gère toutes les fenêtres du système, en suivant le focus d'entrée, et en distribuant les événements (actions de la souris ou du clavier) vers les applications appropriées.

Dans la pratique, Quartz Compositor réside à l'intérieur de Window Server, et Quartz 2D est implanté comme une série de bibliothèques. Mac OS X a d'autres APIs de dessin que Quartz 2D. Open GL, QuickDraw, et QuickTime sont aussi des façons de fournir un contenu matriciel, que Quartz Compositor peut ensuite rajouter sur l'écran.

Comme Quartz Compositor ne fonctionne qu'avec des données matricielles (c'est à dire bit-map) ; le résultat de chaque commande de dessin doit être stocké quelque part dans des tampons de mémoire. Ces tampons sont aussi appelés "backing stores", et il y en a pour chaque fenêtre du système.

Quartz Compositor lit tous ces "backing stores", et les combine en une seule scène qui est alors envoyée sur la mémoire image de la carte vidéo. Cette mémoire image est essentiellement le "backing store" de l'image unique que constitue l'écran tout entier.

Le système ressemble à ceci :
listing

Les choses deviennent plus intéressantes quand on commence à regarder quels éléments matériels sont impliqués dans chaque partie du système. Bien que le modèle conceptuel soit resté le même, l'implantation a changé complètement avec le développement de Mac OS X.

Open GL a été accéléré par le matériel dès le début. C'est, après tout, l'une des deux APIs que les cartes vidéo modernes sont conçues pour accélérer (Direct X étant l'autre). Nous allons voir l'accélération de QuickTime plus tard. Il reste Quartz 2D et QuickDraw, les deux APIs générales de dessin de Mac OS X.

Quartz 2D est l'API de dessin "native" de Mac OS X. Elle a été créée à peu près à partir de rien pour Mac OS X 10.0, et elle reste la façon recommandée de dessiner sur l'écran. QuickDraw est la vénérable API de dessin révolutionnaire du temps de Mac OS classique, qui a permis au premier système d'exploitation avec Interface graphique Utilisateur (GUI) de tourner sur un CPU Motorola 68 000, avec 128 Ko de RAM. QuickDraw est supporté par Mac OS X pour fournir une compatibilité rétrograde avec les applications Carbon portées à partir de Mac OS classique.

L'histoire de l'implantation de Quartz

Quand Mac OS X fut introduit en 2001, la division du travail s'effectuait ainsi :

Quartz

Quartz dans Mac OS X 10.0 - 10.1

Les valeurs de bande passante sont un peu trompeuses, parce qu'elles représentent l'état de l'art en 2005 : un Power Mac G5, avec une carte vidéo ATI X800. Il n'existait rien de tel quand Mac OS X 10.0 est sorti. J'ai choisi de conserver ces valeurs de bande passante pour insister sur les différences architecturales entre les implantations de Quartz. Les différences de matériel interviennent à l'occasion, mais en moyenne, considérons les rapports entre les valeurs de bande passante plutôt que les valeurs absolues.

Dans l'implémentation de Quartz pour Mac OS X 10.0, le CPU fait visiblement l'essentiel du travail. Chaque composant majeur du système s'exécute sur le CPU, et ce dernier est impliqué dans à peu près tous les transferts de données. La seule exception est le dessin final sur l'écran, accéléré matériellement (dans la mémoire image, en fait ; la carte vidéo assure l'affichage de la mémoire image sur l'écran).

Comme la tâche principale de Quartz Compositor est de mélanger les "backing stores" de chaque fenêtre en une scène unique et cohérente, un accès accéléré à la mémoire image n'est pas d'une grande utilité tant que le travail de composition n'est pas terminé. Ensuite, oui, la scène terminée peut être balancée dans la mémoire image sans intervention du CPU.

Ce niveau d'accélération matérielle est en réalité inférieur à ce qui existait dans Mac OS classique. Le modèle d'affichage QuickDraw utilisé dans Mac OS classique n'était pas un moteur de composition. A la place, des applications contrôlaient les portions de l'écran où leurs fenêtres étaient affichées, et pouvaient basculer les pixels (on et off) dans ces zones sans s'occuper de ce que les autres applications avaient à faire. Un accès directe à la mémoire image était donc autorisé pour chaque application qui le réclamait.

Par dessus cela, les cartes vidéo contemporaines supportaient ce qu'on appelle "l'accélération QuickDraw". Les commande de dessin de QuickDraw étaient traduites par le pilote vidéo, puis envoyées directement à la carte vidéo. La carte vidéo assurait alors le dessin, en modifiant sa mémoire image en conséquence, pour tracer les lignes, les formes, et tout ce que les commandes imposaient.

Les applications qui fonctionnaient sous Mac OS X 10.0 n'avaient aucun de ces avantages, et cela se voyait ; Mac OS X 10.0 était lent. Le CPU avait à travailler tout le temps, d'abord pour décider ce qu'il devait dessiner en réponse aux commandes de dessin de chaque application, puis pour composer les "backing stores" de chaque fenêtre, pour en faire la scène finale. C'était beaucoup de dessin, beaucoup de mélanges, et un gros trafic entre le CPU et la mémoire principale (RAM). Rappelez-vous aussi qu'au moment de 10.0, le bus entre le CPU et la RAM était à 100 MHz -avec de la chance ! C'était pénible.

Le moteur Quartz fut optimisé dans Mac OS X 10.1, et le matériel alla un peu plus vite (Oh, un bus à 133 MHz entre le CPU et la RAM !). Mais la division du travail resta la même jusqu'à Jaguar, Mac OS X 10.2 en 2002. L'implantation de Quartz dans Jaguar ressemblait à ceci :

Quartz dans jaguar

Quartz dans Mac OS X 10.2 - 10.3

Jaguar déplaça effectivement Quartz Compositor sur la carte vidéo. Il le fit en modifiant Window Server en une application Open GL. Chaque fenêtre était traitée comme une surface 2D, avec le "backing-store" définissant la texture. Comme la carte vidéo était déjà conçue pour accélérer Open GL, cette modification fit de Quartz Compositor, un complément parfait des possibilités du GPU.

Cette accélération matérielle de Quartz Compositor fut appelée Quartz Extême. Cela ne fonctionnait que sur les cartes qui supportaient des dimensions de texture arbitraires (puisque le "backing store" d'une fenêtre peut avoir potentiellement n'importe quelle taille), et cela nécessitait un bus AGP 2x pour que la carte vidéo puisse efficacement lire les backing stores directement à partir de la RAM.

Le déplacement de Quartz Compositor sur la carte vidéo réduisit considérablement la charge du CPU sous Quartz. Tous ces mélanges ennuyeux de pixels, c'est exactement ce pour quoi est fait un GPU. Cela libéra aussi le CPU de la tâche de transférer les pixels du backing store à la carte vidéo. Déplacer des pixels d'un endroit à un autre n'est à coup sûr pas un bon usage de la puissance du CPU, particulièrement quand les vitesses du bus frontal plafonnent en dessous de 200 MHz.

Les effets de Quartz Extrême furent aisément ressentis. Mon test favori était d'agiter une fenêtre transparente par dessus une séquence QuickTime. Pour respecter le modèle conceptuel de Quartz, la zone sous la fenêtre transparente devait être recomposée à chaque fois, ou que le fenêtre se déplaçait, ou qu'une nouvelle trame vidéo était affichée.

Sans Quartz Extrême, sur ce qui était un Mac rapide à l'époque, (un Power Mac G4 800 MHz), agiter la fenêtre transparente utilisait tellement de temps CPU que la séquence QuickTime manquait des cycles, et s'abaissait à moins de la moitié de son taux normal de balayage. Rajouter 5 fenêtres stationnaires transparentes supplémentaires au dessus de la séquence QuickTime, tout en agitant le fenêtre supérieure, utilisait effectivement 100 % du CPU. La séquence QuickTime s'arrêtait, tout simplement : zéro trame par seconde.

Avec Quartz Extrême validé sur le même Mac, la séquence vidéo se maintenait solidement à 24 trames par seconde. J'ai effectivement essayé de rajouter jusqu'à 25 fenêtres avant de renoncer. Le taux de balayage de la séquence QuickTime ne bougea jamais.

Comme pour Mac OS X 10.1, la version 10.3 Panther avait rajouté des optimisations logicielles à Quartz, mais elle ne changea pas la division du travail. Alors, quelle est la suite ?

Quartz sous Tiger

Avec l'arrivée de Quartz extrême, le CPU n'avait plus à mélanger les tampons des fenêtres, ou les transférer sur la carte vidéo. Malheureusement, les tampons des fenêtres ne jaillissent pas complètement formés, de l'application jusqu'au backing store en RAM. Il faut que quelque chose dessine le contenu de chaque fenêtre dans le backing store.

Par exemple, une fenêtre Safari est pleine de texte, de graphiques, de boutons, et toutes sortes de choses. Bien sûr, c'est bien de récupérer la fenêtre Safari terminée, entièrement dessinée sur l'écran pas Quartz Extrême, sans intervention du CPU. Mais à moins que le fenêtre de Safari ne soit transparente, (ou cachée derrière des fenêtres plus transparentes, cette tâche est peu de choses en comparaison du tracé effectif du contenu de la fenêtre la première fois).

Imaginez du texte seul. Tous ces petits caractères doivent être mis en matrice à partir de leurs définitions de fontes vectorielles, puis il faut appliquer l'anti-crénelage, et mélanger avec le fond. Rappelez-vous que Quartz Extrême ne fait qu'accélérer Quartz Compositor, et que Quartz Compositor ne s'occupe que de tampons de fenêtre complets. Tout mélange qui doit être fait pour dessiner réellement l'un de ces tampons de fenêtre est la tâche du CPU. Ce n'est qu'après que le dessin est complet que le tampon de fenêtre est passé à Quartz Compositor.

Le tracé intervient à chaque fois que le contenu d'une fenêtre change. A côté du tracé initial complet d'une fenêtre, deux autres cas courants viennent à l'esprit : le balayage, et le re-dimensionnement des fenêtres. Le balayage peut obliger le contenu entier de la fenêtre à être re-dessiné plusieurs fois par seconde. Selon la façon dont le contenu de la fenêtre change, son re-dimensionnement peut provoquer la même chose.

Dans ces circonstances, la vitesse de tracé peut être quantifiée par un "taux de balayage" (le nombre d'images dessinées par seconde) comme dans un jeu 3D. Pour emprunter (et en modifier légèrement la signification) un peu plus de terminologie aux jeux 3D, avant l'avènement de Quartz Extrême, Quartz était souvent "limité par le taux de remplissage". Dans des situations qui exigeaient de grandes zones de mélange sur plusieurs couches, Quartz Compositor ne pouvait tout simplement pas composer la scène assez vite pour maintenir un bon taux de balayage sur l'ensemble de l'écran.

Après l'arrivée de Quartz Extrême, le tracé est souvent "limité par le CPU". Composer la scène terminale, en mélangeant tous les tampons de fenêtre n'est plus le goulot d'étranglement. Le GPU prend cela comme un petit déjeuner. Mais le système passe la majeure partie de son temps à attendre que le contenu de tous ces tampons de fenêtres soit créé d'abord.

Il est clair que la solution est d'augmenter considérablement la vitesse de tracé, mais comment ? Pour répondre à cette question, reconsidérez les deux diagrammes précédents de l'implantation de Quartz. En plus de la bande passante et de l'implication du CPU, il y a quelque chose d'autre à prendre en compte à propos des lignes de flux de données qui relient les différentes parties du système : la taille des données qui doivent transiter par ces lignes.

Les résultats du processus de tracé (les images matricielles) sont gros, et réclament beaucoup de bande passante. Les commandes de tracé sont petites. La meilleure solution est de s'assurer que les transferts de données les plus gros passent par les tuyaux les plus gros, et laissent les petits tuyaux s'occuper des données plus petites.

L'implantation de Quartz pour Jaguar/Panther n'est pas des meilleures de ce point de vue.

Quartz sous Jaguar/Panther

Quartz dans Mac OS X 10.2- 10.3

Le CPU est utilisé pour fournir des résultats de tracé matriciels qui sont stockés dans la RAM. Le processus a environ une bande passante de 5 Go/s sur un Power Mac G5 rapide. Quand le tracé est complet, la carte vidéo doit récupérer cette image terminée du backing store en RAM. Bien que cela ne fasse pas intervenir le CPU, la carte vidéo ne peut transférer les données qu'à 2,1 Go/s sur un bus AGP 8x. C'est la bande passante la plus faible du diagramme, mais elle doit transporter les plus gros flux de données.

En plus des contraintes de bande passante, il y a un problème significatif de synchronisation inhérent à l'implémentation de Quartz dans Jaguar et Panther. Quand une application a fini de dessiner dans le backing store de la fenêtre, elle signale à Quartz Compositor que sa fenêtre est prête à être tracée (flushed) sur l'écran. Pour remplir l'écran, Quartz Compositor doit lire le backing store de la fenêtre dans la RAM (par un tuyau étroit), puis le mélanger à l'écran.

Pendant que le tampon de la fenêtre est lu par Quartz Compositor, l'application peut écrire dedans. Autrement dit, la prochaine trame des contenus de la fenêtre ne peut pas être tracée tant que Quartz Compositor n'a pas fini d'aspirer la trame précédente. L'inverse est vrai aussi : Quartz Compositor ne peut pas commencer à lire les pixels du backing store de la fenêtre tant que l'application n'a pas fini d'écrire dedans.

La conclusion, c'est que, avec le tracé et la composition utilisant des matériels séparés (CPU/GPU), avec des mémoires locales séparées (RAM, VRAM), les ressources qu'ils se partagent (les backing stores de fenêtres en RAM), provoquent un goulot d'étranglement et de synchronisation dans le système de tracé. Combiné avec les tuyaux étroits empruntés par les ressources partagées (en comparaison avec les données massives qui doivent être transférées), cela limite effectivement le taux de balayage maximum du système de dessin de Jaguar et de Panther.

La solution est simple : éliminer les goulots d'étranglement existants sur la synchronisation et la bande passante, en déplaçant Quartz 2D dans la partie du bloc diagramme où se trouvent des lignes rouges épaisses, la carte vidéo. C'est là qu'entre en scène Quartz 2D Extrême (Q2DE).