Si OS X n'utilise pas le serveur X, alors qu'utilise-t-il ?

Il utilise Quartz . Mais c'est un peu un terme de marketing dans la mesure où il n'y a pas une seule chose appelée Quartz, mais un groupe de choses qui fonctionnent ensemble pour faire le système appelé Quartz. Plus précisément, Quartz englobe l'ensemble des systèmes nécessaires au rendu (Quartz 2D), à la gestion des polices, à l'interaction avec la carte graphique (Quartz Compositor), à la prise en charge d'OpenGL, à l'accélération 3D, etc.

Le compositeur Quartz est la partie du bundle Quartz qui fournit les fonctions de composition et de gestion du serveur et des fenêtres normalement réalisées par la paire XServer et XClient.

Un addendum à cette question pourrait être : pourquoi Apple n'a pas simplement utilisé X11 et le serveur X ?

Et il y a a grand réponse à la question de l'addendum sur Slashdot de l'un des principaux développeurs de Quartz :

Ce qu'Apple fournit, c'est un système de fenêtres original d'Apple qui est agnostique aux modèles graphiques, ainsi qu'un système de dessin vectoriel qui s'adapte très bien au PDF, qui est une sorte de PostScript sans les opérateurs non-graphiques. Tout cela est regroupé sous le nom de 'Quartz' pour une référence facile pour les types de marketing.

Le système de fenêtres est conçu pour prendre en charge à la fois la mise en mémoire tampon (comme dans le cas d'une (comme un PixMap hors écran) et non tamponné, et est agnostique au modèle graphique graphique, fonctionnant aussi bien avec QuickDraw, OpenGL, le moteur de dessin Quartz, X11 et des solutions tierces. X11 et des solutions tierces, et gère la géométrie des fenêtres. géométrie des fenêtres pour les environnements Classic, Carbon et Cocoa. La partie serveur est une hybridation des modèles d'arbitre d'écran et de compositeur. (et si cela vous paraît trop geek, ne vous en faites pas).

Le moteur de dessin de Quartz prend en charge des primitives de dessin similaires aux primitives graphiques que l'on peut trouver dans la bibliothèque DPSClient bibliothèque de primitives à opérateur unique pour X et NeXTSTEP. Il n'y a pas de primitives primitives mathématiques et de contrôle de flux, car elles peuvent être réalisées plus plus efficacement dans le code compilé natif. Il n'y a pas de wrappers DPS ou PS car cette optimisation pour les graphismes côté serveur n'est pas nécessaire dans le modèle graphique côté client de Quartz.

Les opérations permettent la construction et le remplissage d'images et de chemins ainsi que d'autres opérations intéressantes qui s'inscrivent bien dans la la direction que prend le dessin 2D. (Voir Longhorn, ou les projets X raster projects). Le moteur de dessin peut produire des rasters (comme une fenêtre window !), ainsi que des flux PS et PDF pour alimenter les imprimantes. Le système d'impression de Mac OS X tire parti des capacités de Quartz pour supporter toutes sortes d'imprimantes et Quartz pour prendre en charge toutes sortes d'imprimantes et faciliter la vie des développeurs de beaucoup, beaucoup plus facile.

Les choses que nous devrions ajouter/étendre dans le logiciel X Window (protocole+serveur+gestionnaire+fontes+...) :

1. Étendre le serveur et les services de polices pour vendre des contours et de l'anticrénelage. antialias, supporter plus de types de polices, gérer les sous-ensembles de polices.
2. Étendre les primitives de dessin pour inclure des opérations de chemin de type PS.
3. Ajouter des contrôles de dithering et de phase.
4. Ajout de la prise en charge de ColorSync pour le dessin et opérations de dessin et d'imagerie, l'étalonnage de l'affichage
5. Ajouter un large canal alpha et le compositing Porter-Duff, à la fois pour le dessin dans une fenêtre et pour le dessin dans une autre fenêtre. pour les interactions entre les fenêtres.
6. Ajout d'un support pour les affines générales de Windows
7. Ajout du support pour les maillages de Windows
8. Faire Assurez-vous que la prise en charge d'OpenGL et du matériel spécial de lecture vidéo est intégré, et se comporte bien avec tous les changements ci-dessus.
9. Nous constatons que nous diffusons généralement 200 Mb/sec de commandes et de textures pour une l'utilisation interactive d'OpenGL, donc l'efficacité du transport pourrait être un problème.

Donc, oui, il semble que nous pouvons utiliser X pour Quartz. Tout ce que nous devons faire est définir des extensions pour le serveur de polices et le mettre à jour, ajouter le tramage avec des contrôles de phase au moteur de marquage de X, ajouter un modèle de transparence à X. de phase au moteur de marquage de X, ajouter un modèle de transparence à X l'imagerie avec le support du compositing Porter-Duff, s'assurer que GLX est intégré, mettre à niveau la mise en mémoire tampon des fenêtres pour inclure la transparence, les déformations de maillage, et et un très bon rééchantillonnage, et peut-être augmenter un peu la couche de transport.

Ummm... Il ne semble pas y avoir beaucoup de code restant de l'original X dans le chemin de dessin ou dans la machinerie de fenêtrage, et il ne semble pas pas que les applications qui s'appuient sur ces extensions puissent fonctionner avec n'importe quel autre autre serveur X. Qu'avons-nous gagné dans tout cela ?

Oh, oui. Ma mère peut lancer une session xterm sur son bureau maintenant sans télécharger le paquet X11 d'Apple, un serveur X en shareware ou acheter un logiciel.

J'ai été là, j'ai évalué ça.