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

Mountain Lion : la revue de Ars technica (16)

Là où Lion a trébuché, Mountain Lion regroupe et va de l'avant.

Par John Siracusa, 25 Juillet 2012


Rétina et HiDPI

Le Mac a tenté de séparer son interface utilisateur de la tyrannie de la grille de pixels depuis longtemps déjà, - si longtemps que, à chaque fois que j'ai essayé d'aborder ce sujet dans mon rapport, je me suis trouvé à utiliser des phrases et des métaphores que j'avais déjà employés dans les rapports précédents. La route a été longue et sinueuse (vous voyez ? je recommence), mais, l'année dernière, OS X s'est finalement décidé à suivre les pas d'iOS, bien qu'en abandonnant ses tentatives de gérer des rapports d'échelle arbitraires, et en adoptant un facteur d'échelle strict de 2x appelé "Mode HiDPI".

Ce qui manquait à Lion, c'est un Mac avec un affichage de densité rétina sur lequel installer le truc, avec un chargement de graphiques d'interface utilisateur en double résolution pour empêcher les choses de s'afficher mal. Et bien, maintenant, il est là : le MacBook Pro 15 pouces Rétina. Et c'est sûr; il a été livré avec Lion, avec cependant une construction spéciale de OS X 10.7.4 (11E2068, plus tard mise à jour à 11E2620).

Mountain Lion, bien sûr, hérite des mêmes possibilités. Voici une copie d'écran cérémonielle de notre vieux TextEdit toujours opérationnel, avec sa glorieuse résolution rétina.

figure

Fig. 1 : des pixels si aiguisés que vous pourriez vous couper.

Je parle de cela en partie pour mettre un terme à la saga de la densité des pixels, et en partie à cause de la façon surprenante avec laquelle Apple a apporté le support rétina à OS X. L'année dernière, tous les signes pointaient sur un Mac rétina avec un doublement strict de la résolution d'écran, tout en gardant aux autres éléments de l'interface utilisateur la même taille physique. La simplicité de cette approche est ce qui a permis à iOS une transition si douce vers les affichages rétina.

Mais, ouvrez la vitre des Préférences "Moniteurs" sur le MacBook Pro Rétina, et vous allez trouver cinq choix de résolution. Qu'est-il arrivé à l'unique facteur d'échelle 2X ?

En ce qui concerne les applications, à tout moment, elles effectuent leur tracé avec l'un des deux facteurs d'échelle possibles, 1x ou 2x. La même chose intervient pour les graphiques en bitmap, qui doivent fournir des versions en 1x ou 2x. OS X fournit à l'utilisateur 5 choix différents de résolution d'écran non pas en ajoutant plus de facteurs d'échelle que les applications devraient gérer, mais en utilisant des résolutions "virtuelles" d'écran qui sont des multiples non entiers de la résolution native du panneau LCD.

Par exemple, la résolution de droite, le choix de résolution le plus haut proposé dans la vitre de préférences "Moniteurs" sur un MacBook Pro Rétina de 15 pouces crée un écran virtuel de 3840 X 2400 pixels sur lequel les applications qui connaissent rétina peuvent dessiner en utilisant un facteur d'échelle de 2x, ce qui en fait réellement un affichage en double densité de 1920 x 1200. L'image d'écran résultante de 3840 x 2400 pixels est alors ramenée à l'échelle de l'écran LCD réel à la résolution de 2880 x 1800.

En fait, une seule des cinq résolutions proposées utilise effectivement l'affichage avec un multiple entier de sa résolution native : l'option par défaut "Best (Retina)" qui spécifie un affichage 1440 x 900 en double densité. Tous les autres modes sont tracés sur un écran virtuel qui a été mis à l'échelle, en plus ou en moins, pour cadrer avec l'affichage physique.

Les cinglés de technologie qui liront ceci pourront reculer d'horreur à l'idée de faire marcher un panneau LCD à une résolution non native, mais Apple a trouvé une faille. Bien sûr, la mise à l'échelle d'une grande image virtuelle pour s'adapter à un écran plus petit élimine nécessairement de l'information. Et oui, la mise à l'échelle d'un petit écran virtuel pour s'adapter à un écran plus grand étale l'image et la rend floue. Mais il se trouve que, quand on a 220 pixels par pouce linéaire d'espace sur l'écran, cela peut cacher beaucoup, beaucoup de défauts. Bien que la résolution "native" (en 2x) de 1440 x 900 apparaisse effectivement la meilleure, les autres résolutions ne se présentent pas mal du tout.

Le seul inconvénient de cette approche est qu'on repousse effectivement les limites de ce que les matériels graphiques peuvent supporter. Les résolutions les plus élevées subissent un coup (ou coût) de performance pour des opérations aussi simples que le défilement. Mountain Lion facilite un peu les choses en proposant des applications avec des méthodes pour réduire le nombre de trajets qu'un pixel doit faire entre le CPU/RAM et le GPU/VRAM (par exemple, Safari 6 utilise Core Animation pour améliorer les performances de défilement).

On dit aussi qu'Apple a ré-écrit ses propres routines de mise à l'échelle d'image sur écran, à la fois pour l'Intel HD 4000 intégré, et pour les GPUs NVidia GeForce GT 650M du MacBook Pro Rétina, tout cela pour assurer une étroite correspondance avec la sortie, à mesure que l'OS change de GPUs de façon dynamique quand c'est nécessaire.

Il y a une dernière difficulté. En 2007, Apple mit fin définitivement à Carbon, l'API de transition chargée de porter les applications Mac OS Classique vers OS X, mais sans fournir de support en 64 bits pour les applications Carbon. Maintenant, à peu près toutes les applications Mac sont en 64 bits, et donc, pas sous Carbon. Même Photoshop a laissé Carbon sur la touche. Il reste encore quelques retardataires.

Cela concerne notre sujet, parce que les applications Carbon sont obligées de dessiner à un facteur d'échelle 1x dans les versions d'OS X qui supportent les affichages rétina. Les images qui en résultent sont alors agrandies comme il faut pour avoir la taille correcte sur un affichage en double densité.

En d'autres termes, alors que les applications cocoa obtiennent un texte plus net et des graphiques plus détaillés sur un affichage rétina, les applications carbon paraissent floues. Quoi que cela puisse aussi être vrai d'applications Cocoa qui ne tirent pas correctement avantage de l'affichage rétina, ces applications peuvent être corrigées à l'aide de quelques modifications de code. Pour les applications Carbon, la seule option possible est une conversion complète à Cocoa. Mais cette chose là est écrite sur le mur depuis 5 ans déjà.

Globalement, je parlerais de fin heureuse pour le support d'affichage en haute résolution sous OS X. Les utilisateurs ont plusieurs choix de résolution, tandis que les développeurs n'ont besoins d'en connaître que deux. Dans les prochaines années, je m'attends à ce que les affichages rétina se répandent sur toute la ligne de production des Macs. Au final, l'OS y est prêt.


Scene Kit

Depuis les premiers débuts, Mac OS X a été défini par ses effets visuels. Son système d'affichage en composition permettait un usage extensif de la transparence, des animations comme l'effet génie du Dock, et de détails délicats comme le fondu enchaîné ou des animations en zoom.

Apple a mené la charge avec les effets visuels dans toutes ses applications. Dans les premières années de Mac OS X, les développeurs tiers qui voulaient que leurs applications paraissent aussi bien que celles d'Apple étaient livrés à eux mêmes. Alors qu'Apple avait plein d'experts en graphique parmi ses employés pour rajouter des animations même sur des applications secondaires comme les Préférences système, les développeurs Mac indépendants d'applications non spécialisées dans le graphisme avaient peu de chance d'accéder à cette expertise.

En 2007, Apple a introduit Core Animation comme élément de Mac OS X 10.5 Léopard. Core animation réunissait toutes les APIs de tracé d'Apple dans un unique modèle basé sur des couches. La vidéo, les images, le texte, des contrôles standards comme les boutons et les cases à cocher , et même des scènes avec Quartz Composer pouvaient tous être mélangés librement dans une couche Core Animation. Les couches étaient fortement accélérées par le GPU, et montraient par conséquent une excellente performance.

L'énorme gain pour les développeurs était la facilité avec laquelle les couches de Core Animation pouvaient être animées. Pas besoin d'une connaissance approfondie de la programmation graphique. Le mot " OpenGL" n'avait pas besoin d'être lu ou prononcé. Pour animer quelque chose dans ce monde là, vous définissiez seulement quelques propriétés pour indiquer l'état de la cible (sa position, sa taille, son opacité) et le moteur de Core Animation, à l'aide d'un fil séparé dont vous n'aviez pas à vous préoccuper, faisait tout le travail pénible pour afficher une animation accélérée par GPU en partant de l'état courant, vers l'état de votre cible. Et voilà... le démocratisation de l'animation 2D sur la plateforme Mac.

Mais pour la 3D ? Apple avait tâté aux interface utilisateur 3D depuis des années. La plupart étaient en fait des plans 2D assemblés et animés selon un chemin 3D (par exemple, l'animation de rotation de l'écran lors d'un passage rapide d'un utilisateur à l'autre). Mais que se passe-t-il pour le développeur, disons, d'un livre d'images, qui veut en fournir une version 3D, avec une couverture illustrée, et des pages qui se tournent ?

Soudain, nous étions ramenés aux jours précédant Core Animation , quand de riches graphiques réclamaient une profonde expertise du sujet. La modélisation, les textures et l'éclairage d'un livre d'images 3D est un gros travail. Mais même si cette partie pouvait être réduite, le développeur avait encore à trouver comment intégrer un modèle 3D dans son application, l'afficher, puis le faire réagir aux actions de l'utilisateur. Les graphiques interactifs en 3D sont normalement du domaine des développeurs de jeux, pas de ceux d'un livre d'image. L'ajout d'une telle caractéristique à l'application d'un livre d'images s'apparentait à entreprendre entièrement une nouvelle application de type Jeu en 3D, à l'intérieur du livre d'images.

C'est là qu'entre en jeu Scene Kit, un nouveau framework OS X pour manipuler des scènes 3D. La tâche de création effective de la scène 3D incombe encore au développeur (ou au spécialiste graphique qu'il emploie). Mais, une fois que la scène a été créée et exportée en format DAE, elle peut être lue et comprise par n'importe quelle application Mac qui utilise Scene Kit. (Même Quick Look comprend les fichiers DAE sous Mountain Lion).

C'est un peu superficiel de qualifier Scene Kit de "Core Animation pour 3D", mais c'en est réellement la substance. Il fournit une API de haut niveau en Objective C pour manipuler une scène 3D : position de la caméra, éclairage, propriétés de matériaux, angle de vue, état de surface, tout ce qu'il faut. Le code pour en arriver là ressemble beaucoup plus à Core Animation qu'à OpenGL. Voici un exemple qui charge une scène 3D, prend un objet, et applique une texture dessus.

figure

Cela peut vous sembler complètement incompréhensible, mais soyez sûr(e) que l'équivalent en OpenGL nécessiterait considérablement plus que cinq instructions.

Le code pour l'animation est tout aussi simple, et encore plus proche de celui de Core Animation

figure

Je pense que même des non-programmeurs peuvent comprendre ce qui se passe là. Tout programmeur de Mac qui a utilisé Core Animation se sentira chez lui. Vous pouvez même utiliser les diverses classes CA*Animation de Core Animation pour animer explicitement les propriétés 3D.

Comme pour la vidéo, les images, le texte, et les autres formes de contenu graphique, une scène 3D de Scene Kit peut être affichée au sein d'une couche Core Animation. En outre, les couches de Core Animation peuvent être intégrées dans des scènes de Scene Kit. Vous voulez afficher une vidéo sur une des faces d'un cube en rotation pendant qu'un diaporama de Quartz Composer s'affiche sur les 5 autres faces, avec trois sources de lumière qui tournent autour ? Scene Kit peut le faire.

Apple a présenté Scene Kit aux développeurs en créant une application d'affichage de photos qui utilisait un ensemble de cadres en rotation en 3D pour afficher les images. Le fichier de la scène contenait les cadres avec l'image éclairée et sa texture, disposés sur une table. Le code de l'application partait de là, intervenait dans la scène pour afficher les images comme des textures "derrière une vitre" dans chaque cadre, et faisait tourner la caméra, modifiant les éclairages, et semblait en général stupéfiant, avec une très petite quantité de code, dont aucun de réclamait une connaissance particulière des bibliothèques graphiques de bas niveau.

Pour ceux qui s'y connaissent un peu dans la programmation graphique, Scene Kit fournit plusieurs endroits où les développeurs peuvent ajouter leur propre code OpenGL et GLSL. Bien que je n'attende pas un summum de jeux en 3D qui demandent de la performance construits en utilisant Scene Kit, il est tout à fait possible que des jeux 3D puissent à l'occasion être construits par des développeurs qui n'ont qu'une connaissance très limitée de OpenGL.

Scene Kit est-il une démocratisation de la 3D ? Nous verrons si les développeurs l'adoptent avec autant d'empressement qu'ils ont adopté Core Animation. Le besoin de créer des éléments en 3D est une barrière beaucoup plus haute à l'adoption de Scene Kit que la création d'éléments en 2D ne l'était avec Core Animation. La plupart des applications Mac ont déjà des éléments en 2D ; Core Animation en a rendu l'animation facile. Mais peu d'applications Mac utilisent la 3D.

Je fais les mêmes réserves à propos des interfaces agrémentées de colifichets en 3D, que je l'ai fait avec les interface en 2D animées à l' aube de l'ère de Core Animation. Pour l'essentiel, les développeurs Mac se sont restreints au domaine 2D (quoi qu'Apple soit une possible exception). J'espère que la 3D débarquera sur la plateforme Mac avec une grâce semblable.

Je suis très impressionné par Scene Kit. Ce fut de loin mon nouveau framework favori, cette année, à la WWDC. (Les développeurs enregistrés peuvent voir la session vidéo sur le site d'Apple). Il y a beaucoup plus à en dire que la brève vue d'ensemble proposée ici, y compris la possibilité de créer par programmation des figures géométriques simples. Comme démonstration finale de la façon dont Scene Kit rend le monde de la 3D accessible, voici une copie d'écran d'une application simple que j'ai écrite, et qui montre des possibilités de texte en 3D à l'aide de Scene Kit.

figure

2 images JPEG, 46 lignes de code, aucune expérience en 3D, et Scene Kit !