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 2D Extrême




Ce que Quartz Exrême a fait pour Quartz Composer, Quartz 2D Extrême le fait pour les API de dessin de Quartz 2D. Voilà à quoi l'implantation de Quartz ressemble dans Tiger :

Quartz dans Tiger

Quartz dans Mac OS X 10.4 Tiger

Si vous regardez les trois diagrammes d'implantation de Quartz l'un après l'autre, vous pouvez remarquer comment la portion de la carte vidéo dans le diagramme s'est lentement agrandie pendant quatre ans, pour englober une partie toujours plus grande de la couche d'affichage. La raison est claire quand on voit les valeurs de bande passante : 30 Go/s entre le GPU et la VRAM, -et ce nombre augmente rapidement, beaucoup plus vite que celui de la bande passante entre le CPU et la RAM.

Comme vous pouvez le voir, Quartz 2D fonctionne maintenant sur le GPU. Cela s'appelle Quartz 2D Extrême. La seule chose qui reste à faire au CPU est d'envoyer les commandes de dessin (relativement limitées) à la carte vidéo par l'intermédiaire du pilote.

Cela ne servirait à rien de faire tourner Quartz 2D sur le GPU s'il avait encore à écrire ses résultats dans la RAM, puis à forcer Quartz Compositor à les relire à nouveau. Si bien que Quartz 2D Extrême a aussi déplacé les backing-stores des fenêtres dans la VRAM.

Maintenant, le flux des données est tout à fait convenable. L'application, qui tourne sur le CPU utilise les APIs Quartz 2D pour dessiner son contenu dans sa fenêtre. Les commandes de dessin limitées sont envoyées du CPU à la carte vidéo à travers le pilote de la carte. Quartz 2D tourne sur le GPU, produit les résultats du tracé qui sont alors écrits dans le backing-store dans la VRAM par un énorme tuyau de 30 Go/s. Quand le dessin est fait, Quartz Compositor extrait le backing-store de la VRAM par le même tuyau, et envoie l'image-écran terminée sur la mémoire image à travers un autre énorme tuyau.

Les problèmes de synchronisation sont considérablement réduits par la vitesse avec laquelle les backing-stores peuvent être lus et écrits, et par le fait que le fournisseur et le consommateur des backing-stores fonctionnent sur le même matériel, et disposent de connections identiques à forte bande passante vers le même ensemble de RAM local.

Le démons sont dans les détails

Rien n'est aussi simple que ce qu'un bloc diagramme semble montrer, et l'implantation de Quartz pour Tiger ne fait pas exception. Commençons avec Quartz 2D Extrême. Alors que les commandes de dessin peuvent être limitées, il peut y avoir momentanément des blocs de données beaucoup plus gros qui doivent être envoyés à la carte vidéo. Imaginez que vous affichez une image, par exemple. Cette image doit finir dans le backing-store d'une façon ou d'une autre. Le backing-store est dans la VRAM, et l'image est sur le disque. Malheureusement, la carte vidéo ne peut pas extraire des données directement du disque vers la VRAM. Si bien que de temps en temps, le CPU va devoir insérer de gros blocs de données (comme une image) dans le flux des commandes de dessin limitées qu'il envoie à la carte vidéo.

Une surcharge de gros blocs de données dans le flux des commandes est en réalité quelque chose de potentiellement désastreux. Bien que le chemin entre la RAM et la carte vidéo ne soit pas représenté dans le diagramme sur Quartz sous Tiger, vous pouvez le voir sur le diagramme de Jaguar/Panther. Ce tuyau est le plus petit du diagramme, moins de la moitié de la bande passante du tuyau entre le CPU et la RAM (2,1 contre 5 Go/s). Essayer de faire passer de gros blocs de données par ce tuyau annule tous les avantages de performance que Quartz 2D Extrême peut offrir.

La solution est de n'envoyer les gros blocs de données (images et autres bitmaps) vers la carte vidéo qu'une seule fois, puis de les conserver en cache dans la VRAM. Toute commande de dessin suivante, qui utilisera ces bit-maps peut alors s'exécute immédiatement, en récupérant les données depuis la VRAM sur un gros tuyau.

Une énorme quantité d'opérations courantes de dessin se coulent dans ce moule "chargement, cache, récupération". Par exemple, à peu près n'importe quel élément de l'interface dans Mac OS X est un bit-map : boutons, cases à cocher, widgets de fenêtres, textures de fond de fenêtres, etc... La première fois que ces éléments d'interface utilisateur sont tracés, le graphique bit-map est chargé dans la carte vidéo et mis en cache dans la VRAM. Toutes les commandes suivantes de dessin des widgets peuvent ensuite s'exécuter très vite, en récupérant les bit-maps du cache de la VRAM quand c'est nécessaire.

D'une façon surprenante, le texte est aussi un exemple courant. La première fois que du texte est dessiné avec une taille donnée dans une fonte donnée, les formes des caractères (glyphes) sont lus dans une définition vectorielle de fonte, puis mis en bit-maps pour la taille spécifiée. Ces glyphes en bit-map sont alors chargés sur la carte vidéo et mis en cache dans la VRAM. Tous les tracés de textes suivants qui utilisent la même fonte et la même taille peuvent alors envoyer une simple commande de dessin (dessine la lettre majuscule "A") sans avoir à en recharger l'image. Comme la plupart des texte consistent en une longue séquence de glyphes dans quelques fontes et dans quelques tailles, c'est un gain énorme en pratique. Bien sûr, des typographies complexes avec des fontes de types et de tailles différentes, n'en bénéficieront pas autant, mais tout dépend alors de la taille de VRAM dont vous disposez.

Cela nous amène à la réalité la plus pénible de ce brave nouveau monde du dessin par GPU : la VRAM est limitée. Le diagramme montré plus haut a caché cette réalité sous le tapis. Que se passe-t-il quand il n'y a plus assez de VRAM pour mettre en cache tous les backing-stores et tous les bit-maps, et les glyphes en matrices, et que sais-je ? Est-ce que la performance s'effondre ?

En fait, la VRAM a été "virtualisée" sous Mac OS X depuis le début de Quartz Extrême sous Jaguar. Bien que le diagramme Quartz de Jaguar montre le backing-store en RAM, Quartz Compositor est assez habile pour mettre en cache ces backing-stores aussi dans la VRAM. La limitation la plus importante de l'implantation de Quartz dans Jaguar est que le dessin effectif se fait dans le backing-store en RAM, si bien que le diagramme montre la séquence des événements pendant l'opération effective de tracé. Mais tant que le contenu de la fenêtre ne change pas, Quartz Compositor peut continuer à utiliser le cache en VRAM du backing-store, au lieu de relire en RAM à chaque fois.

Même l'implantation de cette forme limitée de cache dans la VRAM a montré que la VRAM n'est pas toujours capable de contenir des copies en cache de tous les backing-stores. Pire, la quantité de VRAM varie avec la carte vidéo utilisée. Pour simplifier l'implantation de Quartz, Jaguar avait besoin que, d'une certaine façon, la VRAM apparaisse "illimitée", bien qu'à l'évidence elle ne le soit pas.

Ce problème avait déjà été résolu avant. Le système de mémoire virtuel des systèmes d'exploitation modernes fait apparaître la RAM "illimitée". En fait, elle apparaît comme si elle contenait 232 ou 264 bits pour des CPUs de 32 bits et de 64 bits respectivement. Mais c'est à coup sûr plus grand que la RAM installée physiquement (notamment dans les systèmes 64 bits).

Bien que les détails soient différents, c'est essentiellement ce qu'a fait Jaguar avec la VRAM. Pour le système d'exploitation, la VRAM apparaît plus importante qu'elle n'est. Quartz s'occupe d'échanger les données entre la VRAM et la RAM quand c'est nécessaire, en utilisant un algorithme optimisé pour conserver dans la VRAM les éléments de données les plus souvent utilisés, aussi souvent que possible.

Dans l'implantation de Quartz sous Jaguar, tous les backing-stores mis en cache dans la VRAM sont de simples copies redondantes des backing-stores en RAM. Tous les backing-stores doivent exister dans la RAM sous Jaguar, parce que c'est l'endroit où le tracé se fait effectivement. Les commandes de dessin de Quartz provoquent la modification des backing-stores en RAM. Le backing-store complet est alors transféré (via DMA) vers la carte vidéo, où Quartz Compositor les mélange avec la scène, et (le cas échéant) les met en cache dans la VRAM, pour le cas où elles auraient besoin d'être utilisées à nouveau, avant qu'elles ne soient modifiées (en RAM, rappelez-vous), par l'application, et ne doivent être à nouveau ré-importées en VRAM.

Sous Tiger, avec Quartz 2D Extrême, les commandes de tracé de Quartz 2D modifient maintenant le backing-store en VRAM. Quartz Compositor, qui tourne aussi sur la carte vidéo, lit depuis le backing-store de la VRAM. Le backing-store de la RAM n'est plus utilisé du tout.

En fait, théoriquement. Rappelez-vous que la VRAM est limitée. Ce qui ne tient pas dans la VRAM doit être à la place stocké dans la RAM. Quand la VRAM est pleine, il y a une danse constante de données, qui passent entre la RAM et la VRAM quand c'est nécessaire, pour conserver (dans l'idéal) les données les plus fréquemment utilisées dans la VRAM. Il y a aussi une autre raison importante pour laquelle le backing-store doit être en RAM plutôt qu'en VRAM.

Avec l'introduction de Tiger, Apple a annoncé que QuickDraw était maintenant dépassé. Il n'y aura plus d'améliorartions de QuickDraw, et il disparaîtra "un jour" de Mac OS X. (C'est à peu près aussi précis que ce qu'Apple a dit). Apple veut que tout le monde passe à Quartz 2D ; cela a été un message consistant depuis Mac OS X 10.0. Les développeurs ont eu quatre ans pour monter dans le train de Quartz 2D. La désaffection de QuickDraw sonne comme une exhortation "tout le monde à bord".

Dans Tiger, Apple donne aux développeurs une autre raison importante d'abandonner QuickDraw. Si une application utilise QuickDraw pour tracer quoi que ce soit dans une fenêtre donnée, cette fenêtre est complètement privée de l'accélération de Quartz 2D Extrême. A la place, tout retombe dans le modèle Jaguar/Panther : le CPU assure le tracé, et écrit les résultats dans le backing-store de la RAM.

Cela peut sembler comme une décision extrême de la part d'Apple, mais elle a du sens. QuickDraw a accumulé plus de vingt ans de comportements non documentés, qui auraient dû être parfaitement conservés dans toute implantation utilisant un nouveau GPU. Le modèle de tracé de QuickDraw est aussi très différent de celui de Quartz 2D. Faire coexister les deux APIs n'aurait pas été facile. Pour dire les choses en douceur, des API désaffectées ne constituent pas un changement aussi radical que celui-ci. Apple a tranché : pas de futur développement pour QuickDraw, et elle s'y tient.

Malheureusement, même Quartz 2D n'est pas entièrement accéléré sous Quartz 2D Extrême. Dans les cas où la gamme actuelle des cartes vidéo ne sait pas faire une opération particulière de dessin, ou ne peut pas la faire avec une qualité comparable avec l'implantation logicielle, ces opérations continuent à se faire en mode logiciel sous Tiger. Heureusement, elles sont rares (des tracés complexes, des lignes avec des jointures angulaires et des terminaisons spéciales, etc...). A mesure que les cartes vidéo s'améliorent je pense que ces opérations finiront pas être supportées.

Cela représente peut-être la limitation la plus importante de Quartz 2D Extrême. Comme Quartz 2D avant lui, Quartz 2D Extrême n'est pas supporté par toutes les cartes vidéo. Il a besoin de cartes ATI Radéo 9600 ou de cartes NVIDIA GeForce FX ou mieux. En terme de technologie, Quartz 2D Extrême nécessite l'extension Open GL ARB_fragment_program.

Et c'est vrai, Quartz 2D Extrême a une autre ressemblance avec Quartz Extrême : il utilise aussi Open GL pour faire le travail. Toutes ces commandes de tracé dans le diagramme de Quartz sous Tiger sont en réalité des commandes Open GL. Il est de plus en plus vrai de décrire un écran entier sous Mac OS X comme une scène Open GL géante.

Les performances de Quartz sous Tiger

Compte tenu de toutes les limites et problèmes décrits ci-dessus, quelle amélioration de performance Quartz 2D Extrême apporte-t-il ? La comparaison d'opérations primitives met Quartz 2D Extrême sous le jour le plus favorable, et révèle une performance théorique maximum. Le tableau suivant montre la vitesse de plusieurs opérations de tracé faites avec le logiciel (sans Q2DE) et avec le matériel (avec Q2DE).

Tracé logiciel ou matériel

Quartz 2D (logiciel) comparé à Quartz 2D extrême (matériel).

Quelques résultats peuvent sembler surprenants, mais la plupart se comprennent si vous considérez les diagrammes d'implantation précédents. Voyez l'énorme amélioration (236 x) dans le remplissage d'un rectangle 800 X 800 ; cela représente essentiellement un test de taux de remplissage : à quelle vitesse l'API peut dessiner 640 000 pixels dans le backing-store, puis passer le backing-store par Quartz Compositor, et enfin en scène finale dans la mémoire image.

Quartz 2D qui fonctionne en logiciel en utilisant le CPU doit écrire dans le backing-store en RAM, puis le backing-store doit être déplacé dans la carte vidéo où Quartz Compositor le dépose dans la scène finale. Quartz 2D Extrême qui tourne sur le GPU écrit ces 640 000 pixels dans la VRAM, où Quartz Compositor va les récupérer directement. Pas de transfert coûteux depuis le backing-store de la RAM vers celui de la VRAM par un tuyau trop étroit.

La prouesse de remplissage de Quartz 2D Extrême explique aussi le résultat du tracé d'image 128 x 128, supérieur à celui d'une image 8 x 8, et ainsi de suite.

Le test de la chaîne de 12 caractères est moindre que ce qu'on pourrait attendre compte tenu du système de mise en cache des glyphes décrit, précédemment. La faible augmentation de vitesse (x 2,7) révèle en fait à quel point l'implantation logicielle de Quartz 2D a été optimisée sous Tiger.

Il apparaît que les optimisations logicielles sous Tiger sont presque aussi importantes que l'accélération matérielle. Prenez par exemple le tracé de ligne. Quartz 2D était connu pour être lent pour le tracé de lignes sous Panther ou les versions antérieures de Mac OS X, à tel point que les développeurs préféraient souvent utiliser (ou persevérer avec) QuickDraw pour de telles tâches.
listing

Inutile de dire que cela n'est pas apprécié, quand une API de tracé désaffectée est plus rapide que la nouvelle qui est proposée. Il fallait faire quelque chose, et voilà le résultat.
listing

On ne peut pas échapper à la barre géante de l'accélération matérielle de Quartz 2D Extrême, mais regardez aussi les performances de Quartz 2D en mode logiciel : cela représentait à peu près la moitié des performances de QuikDraw sous Panther, et c'est passé à cinq fois plus que Quick Draw sous Tiger.

Le tracé de texte a subi les mêmes augmentations impressionnantes pendant la durée de vie de Mac OS X. Sous Tiger, le tracé de texte avec accélération matérielle sous Quartz 2D Extrême n'est que trois fois plus rapide que le mode logiciel. Nous allons reprendre la question de l'optimisation logicielle comparée à l'accélération matérielle dans une prochaine section. Pour l'instant, disons seulement que le tracé logiciel a fait de gros progrès sous Tiger.

Tous ces tests de performance synthétiques sont intéressants, mais comment cette nouvelle technologie se comporte-t-elle dans des cas réels ? A l'évidence, peu d'applications peuvent montrer des améliorations de performances aussi impressionnantes que les tests synthétiques, mais ce n'est pas aussi simple et clair que vous pourriez le penser. Quelques applications sont en réalité passablement plus lentes quand elles tournent sous Quartz 2D Extrême.

Qu'est-ce qui explique cela ? Cela résulte de la virtualisation de la VRAM. Quartz essaie d'être habile sur ce qu'il conserve en VRAM, mais il ne peut pas prédire le comportement futur des applications, sans aide. Quand elles tournent sous Quartz 2D Extrême, les applications sont censées conserver les références aux structures de données de Core Graphics, qu'elles veulent mettre en cache en VRAM. (Core Graphics (CG) est le framework qui implante la majeure partie de Quartz 2D). Le système de virtualisation de la VRAM utilise ceci comme une indication que ces éléments de données seront ré-utilisés bientôt. Mais retenir une référence ne garantit pas à l'élément référencé une place permanente dans la VRAM.

Malheureusement cela ne constitue pas une pratique courante dans les applications Mac OS X. Avant Quartz 2D Extrême, conserver les références de blocs importants de données longtemps après que les choses auxquelles elles s'appliquent aient été utilisées était considéré comme un gâchis de mémoire, ne fournissant aucune amélioration significative de performance. Rappelez-vous que sous Panther et avant, dessiner des gros blocs de pixels était susceptible d'être limité par la bande passante du transfert entre la RAM et la VRAM, plus que par tout autre facteur. Si un bit-map était utilisé pour du tracé répétitif, l'excellent système de cache sur le disque de Mac OS X rendait moins nécessaire la conservation du bit-map dans la mémoire de l'application. Il valait tout aussi bien se débarrasser de la référence, puis récupérer le bit-map à partir de la mémoire (le cache du disque) la prochaine fois qu'on en aurait besoin.

Quand on tourne sous Quartz 2D Extrême, les règles changent. La VRAM est l'endroit où il faut être, et tout de qui n'y est pas doit être récupéré avant que le dessin puisse commencer. Laisser de gros blocs de données en RAM, plutôt qu'en VRAM est comme cumuler les inconvénients des approches de Panther et de Tiger. C'est pourquoi les applications qui se débarrassent des références de toutes leurs données graphiques dès qu'elles en ont terminé avec elles peuvent en réalité devenir un peu plus lentes quand elles tournent sous Quartz 2D Extrême.

Mais c'est un problème facile à résoudre pour les développeurs, et ils devraient maintenant y être habitués. Chaque fois qu'une version majeure de Mac OS X est proposée, il est de la responsabilité des développeurs de réadapter leurs applications. Apple a prévenu en maintes occasions : "Ce qui était bon marché auparavant peut maintenant devenir cher, et vice-versa. ne supposez pas, mesurez !". Le prix de la performance est une éternelle vigilance.

Je suppose que les développeurs d'applications graphiques intensives vont être fortement motivés pour faire cela sous Tiger. Tout ce que cela demande, c'est d'examiner les valeurs de performance pour Quartz 2D Extrême, pour voir si le bénéfice potentiel de retenir quleques références CG supplémentaires justifie le coût de développement.

Quant aux développeurs qui utilisent encore QuickDraw, et bien, ils ont eu quatre ans. Ils vont probablement en avoir encore deux avant que QuickDraw ne disparaisse complètement, mais honnêtement, à un moment donné, il faut savoir s'envoler, et quitter le nid.

Il y a une dernière barrière au bonheur de l'accélération matérielle. Quartz 2D Extrême est invalidé par défaut dans Mac OS X 10.4.0. C'est vrai, cette nouvelle technologie rapide dont je viens de vous parler n'est pas réellement utilisée sous Tiger à moins que vous l'ayez explicitement validée à l'aide de l'application Quartz Debug. Et même dans ce cas, cela ne s'applique qu'aux applications qui ont été lancées après la validation. Il se trouve aussi que Q2DE est à nouveau invalidé quand vous quittez l'application Quartz Debug.

Pourquoi développer quelque chose d'aussi impressionnant que Quartz 2D Extrême, et ensuite le laisser invalidé par défaut ? Mes questions à Apple sont restées sans réponse, si bien que je ne peux qu'imaginer le raisonnement qui est derrière cette décision. Ma meilleure hypothèse est que toutes les bogues n'ont pas pu être éliminées de Q2DE pour la date de lancement de Tiger, et que cela sera validé par défaut dans une mise à jour prochaine, peut-être dès la version 10.4.1.

Résumé sur Quartz

La couche d'affichage Quartz a subi des améliorations fondamentales grâce à l'accélération matérielle dans chaque version paire de Mac OS X (Quartz Extrême dans 10.2, et maintenant Quartz 2D Extrême dans 10.4), avec des optimisations uniquement logicielles dans les versions impaires. Tiger est unique, en ce qu'il fournit des optimisations logicielles considérables en même temps qu'un nouveau niveau d'accélération matérielle.

Quartz 2D Extrême est déjà impressionnant, mais il a la possibilité de devenir encore plus rapide et plus puissant. (La première étape sera de le valider par défaut, bien sûr). Les cartes vidéo évoluent beaucoup plus vite que les autres composants matériels d'un PC moderne (CPU, RAM, disque), aussi bien en termes de performances que de possibilités. Déplacer (presque) toutes les fonctionnalités de tracé du CPU au GPU met Mac OS X en bonne position pour récolter les bénéfices des futures inovations des cartes vidéo. Comme nous allons le voir dans la prochaine section, Quartz 2D n'est pas la seule API qui aspire à prendre le train regorgeant de richesses du GPU. La carte vidéo devient passablement encombrée, par les temps qui courent...