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

Core Animation




Dans son époque post Mac OS X, Apple a porté un gros intérêt à rajouter de l'animation à ses applications, et à l'OS lui-même. On trouve des exemples partout : les items de la liste des amis proches, dans iChat, changent d'intensité, et se ré-alignent tout seuls quand un nouvel item apparaît ; le changement de vitre des préférences déclenche un fondu enchaîné et un re-dimensionnement animé de la fenêtre ; les items du Dock s'alignent et s'écartent quand un nouvel item est posé dessus.

Trop d'animation peut être gênant et irritant. Mais dans les meilleurs cas, ces animations facilitent réellement l'usage en fournissant une explication visuelle explicite des changements d'état, en même temps qu'elles ont un charme indéniable.

D'une façon très compréhensive, les développeurs indépendants ont longtemps cherché à imiter ces effets. Dans le passé, c'était une entreprise très difficile. Prenez quelque chose d'aussi simple que le fondu enchaîné entre des vitres de préférences dans l'application Préférences Système. Un développeur, qui crée, disons, un éditeur de texte, peut être tenté d'utiliser le fondu enchaîné dans sa fenêtre de dialogue Préférences.

Mais faire cela l'entraîne loin de son espace de confort, dans le monde des APIs graphiques, et peut-être même dans OpenGL. Qu'est-ce que cela a affaire avec l'édition de texte ? Bien sûr, Apple peut se permettre de faire appel à un de ses gourous en graphisme pour ajouter des effets innovants, mais c'est une autre affaire, pour les petits développeurs, que de prendre le temps d'apprendre un tas de nouvelles APIs, sans relations avec les fonctionnalités réelles de leurs applications. Et pour quoi ? De la poudre aux yeux ?

Mais ils ont essayé, et ont rapidement accru le nombre des applications Mac qui contenait du code Core Graphics et/ou OpenGL de médiocre qualité, pour des raisons douteuses. Que pouvait faire Apple ?

La motivation semble admirable : les développeurs indépendants veulent que leurs applications soient aussi belles que celles d'Apple. En général, ce n'est pas quelque chose à décourager. Mais c'est vraiment très inefficace que d'avoir tous ces développeurs, qui cherchent à écrire du code personnalisé très en dehors de leur champ d'expertise.

Et en matière d'efficacité, ce n'est pas non plus une bonne idée pour Apple de faire la même chose. Bien qu'ils aient les talents sur place, Apple serait mieux servi à faire travailler ses experts en graphisme sur des APIs que tout le monde peut utiliser, plutôt que de rajouter du code personnalisé de fondu enchaîné à encore une autre de ses applications maison.

Si bien que, dans Léopard, Apple a introduit Core Animation. Une nouvelle sphère stylisée violette pour accompagner ses voisines.

Core frameworks

Les frameworks d'animation peuvent facilement s'épanouir en une révision complète de l'entière API graphique. Après tout, un élément statique d'interface n'est-il pas tout simplement une forme dégénérée d'animation ? Réimplantons tout à l'aide de notre nouveau framework d'animation ! Ça va être extra !

Cela risque aussi d'être tardif, incompatible, plein de bogues, et lent, sans parler de la résistance des développeurs, qui ne sont pas chauds à réécrire leur code graphique depuis le début pour utiliser les nouvelles APIs d'animation.

Heureusement, Apple s'y est pris autrement avec Core Animation. Comme pour les FSEvents, Core Animation est une API pragmatique. Elle fait un petit nombre de choses bien choisies, et elle les fait très bien. Elle s'est aussi évertuée à rendre cette fonctionnalité disponible pour les applications existantes avec extrêmement peu de changements dans le code.

Le nom original de Core Animation, Layer Kit, en dit beaucoup sur sa conception. Au cœur, Core Animation gère une collection de couches 2D. Bien que ces couches soient classées par profondeur, et peuvent subir des transformations en perspective, Core Animation n'est pas un moteur 3D. Autrement dit, les couches peuvent se superposer, mais elles ne peuvent pas se couper (au sens 3D du terme).

La distinction 2D/3D est encore rendue plus confuse du fait que Core Animation, comme tout graphique sous Mac OS X, tourne (bien qu'indirectement) au sommet d'OpenGL. Les démos d'Apple "3D" Core Animation (environ 52 minutes dans la session d'introduction de la WWDC 2006) n'ont pas aidé. Mais soyez sûr que vous ne pourrez construire aucune théière avec Core Animation. Il n'y a pas de vertex, de triangles, et d'éclairage dans l'API de Core Animation. C'est un layer kit, rappelez-vous. Pensez "pas de plans 2D qui se coupent dans l'espace".

Mais de quels plans s'agit-il ? D'abord, chaque couche a les propriétés suivantes : géométrie, arrière-plan, contenu, des filtres, l'ombre portée, l'opacité, et un masque. Chaque couche peut avoir zéro ou plusieurs sous-couches, et les filtres sont ceux de Core Image, bien sûr. Mais c'est le contenu de la couche qui est la partie vraiment intéressante.

A un moment, pendant pratiquement toutes les WWDC depuis l'introduction de Mac OS X, un ingénieur d'Apple est venu expliquer comment mélanger le contenu fourni par des APIs différentes : du texte vectoriel superposé à une scène OpenGL, comment mettre un bouton standard ou une case à cocher sur une animation QuickTime, ou appliquer un filtre de Core Image pour différencier une boîte de dialogue, et ainsi de suite. Ces démonstrations étaient compliquées, mettaient souvent en jeu des fenêtres spéciales d'incrustation, des conversions manuelles de l'espace des couleurs, et des duplications de données extravagantes. Inévitablement, l'ingénieur d'Apple était amené à s'excuser pendant la démonstration, et à reconnaître que ce genre de choses ne devrait pas être aussi difficile que ça l'était. Et bien, sous Léopard, grâce à Core Animation (parmi d'autres), c'est maintenant presque trivial.

Les couches de Core Animation procurent pour la première fois dans Mac OS X, une manière aisée de mélanger tous les types de contenus supportés sans restrictions : de la vidéo QuickTime, OpenGL, des dessins de Core Graphics, des scènes de Quartz Composer, des contrôles standard de l'interface utilisateur comme des boutons, des cases à cocher, des menus pop-up, du texte enrichi, tout ce que vous pouvez imaginer. En fait, Core Animation assure l'unification de toutes les choses graphiques dans Mac OS X.

Les couches sont animées d'une façon déclarative plutôt que procédurale. Par exemple, pour faire s'évanouir une couche, fixez simplement son opacité à zéro. Plutôt que de devenir instantanément invisible, la couche va mettre un certain temps à disparaître (0,25 seconde par défaut). Autrement dit, définissez une état final pour chaque couche, et (en option) quelques informations supplémentaires sur la transition, et le moteur de Core Animation va prendre en charge le processus pour modifier effectivement la couche, depuis son état initial vers son état final. Bien que tous les réglages de l'animation soient optionnels, et ont des valeurs par défaut convenables, les animations peuvent avoir des durées configurables, des courbes temporelles, des Keyframes et des modes de transition. Et puis, des modifications multiples de propriétés peuvent être regroupées par lots en une seule modification atomique.

Sous le capot, chaque couche de Core Animation est prise en charge par OpenGL, et se matérialise dans la VRAM de la carte vidéo. (Pour les couches qui dépassent la taille de texture maximum de la carte vidéo, Core Animation fournit une API de couche "en tuile" avec des fonctions de rappel pour récupérer chaque portion de l'image plus grande, quand c'est nécessaire). Les couches de Core Animation sont très légères ; les Macs actuels peuvent animer plusieurs milliers de couches simultanément. L'unification des types de contenu dans les couches de Core Animation donne l'opportunité de consolider beaucoup de mécanismes d'accélération par GPU préalablement séparés pour la vidéo, le dessin 2D, et l'animation en un seul contexte.

La technologie sous-jacente est impressionnante, mais cette énorme victoire a une fin plus prosaïque : la façon dont cette fonctionnalité est expliquée au développeur.

Core Animation dans Cocoa

Sans surprise, Core Animation est une API Cocoa. Polémiques mises de côté, c'est un bon choix. Cocoa dispose déjà de conventions pour observer les changements des propriétés des objets, et Core Animation se branche directement dessus. Mais le trait de génie est dans la minceur de travail nécessaire pour commencer à utiliser Core Animation dans une application existante.

Pour les développeurs, la procédure est simple. Pour permettre l'animation d'une vue, cocher la case appropriée dans Interface Builder, ou faire l'appel suivant [view setWantsLayer:YES] à l'exécution. Cela crée une couche Core Animation pour la vue en question, et toutes les sous-vues qu'elle contient. Le résultat est deux arbres de vues : la collection des vues normales et des sous-vues qui a toujours existé dans votre application Cocoa (les fenêtres, les boutons, etc...), et en parallèle, une hiérarchie des couches de Core Animation qui représente le sous-ensemble des vues normales qui ont leur propriété WantsLayer déclarée.

Chaque vue qui dispose d'une couche Core Animation a un attribut animator. Les appels aux méthodes qui affectent des propriétés animables sont animés quand ils sont faits par cet objet, et non animés quand ils sont faits par la vue elle-même. Par exemple, supposons que nous avons du code pour définir la taille d'une fenêtre dans votre application :

listing

Pour animer cela en utilisant Core Animation dans Léopard, obtenir une fenêtre qui modifie progressivement sa taille entre la taille courante et la nouvelle taille, en utilisant le moteur d'animation accéléré par GPU et basé sur OpenGL, sur un thread séparé, il suffit de taper 11 caractères de plus, comme ci-dessous :

listing

C'est d'habitude le moment dans une présentation à la WWDC où des programmeurs Cocoa non familiers de Core Animation commencent à saliver et à gémir.

Oui, bien sûr, cela devient plus compliqué si vous voulez personnaliser l'animation, mais légèrement seulement. Dans les cas courants, rajouter une animation à votre application Cocoa existante est aussi simple que l'exemple au dessus le montre. Comme premier essai, envoyez seulement tous les appels des méthodes que vous voulez animer par l'intermédiaire de la propriété animator. Comme second essai, personnalisez quelques unes des animations pour les rendre plus rapides ou plus lentes, ou leur donner un peu de fantaisie. Il n'y a pas de troisième essai, comme on dit. Pas de code OpenGL, pas de dessin à faire, pas de programmation du GPU. Ah ... !

Apple est devenu dingue de Core Animation, à la fois dans ses propres applications, et dans Cocoa. Toutes les propriétés visuelles de base peuvent être animées- et quelques autres un peu ésotériques comme la rotation. Oui, si vous avez besoin de créer des boutons tournants, ou des fenêtres inclinées, Core Animation est là pour vous. Vous pouvez même rajouter de nouvelles propriétés animables à vos vues personnalisées.

Apple a aussi créé plusieurs nouvelles vues Cocoa, et des contrôles, qui disposent de fonctionnalités qui auraient demandé des milliers de ligne d'un code complexe avant l'arrivée de Core Animation. Le meilleur exemple la très flexible NSGridView. Cette seule vue peut être utilisée pour créer quelque chose qui ressemble à, et se comporte comme, la liste des amis proches de iChat, ou le Dock, le tout avec très peu de code. Des items qui disparaissent progressivement quand ils sont enlevés, qui s'écartent du passage pour accepter un glisser-déposer, qui se déplacent pour se réorganiser, même la recherche de texte et le filtrage visuel, tout cela est essentiellement "gratuit" avec NSGridView et Core Animation.

Séparation des préoccupations

Comme je l'ai mentionné avant, la partie animation de Core Animation tourne dans son propre processus et a sa propre boucle d'exécution, indépendante de l'application elle-même. Ces deux mondes parallèles - l'arborescence des vues de l'application et celle des vues de Core Animation qui seconde certaines portions de la première- sont largement dissociées. La communication se fait implicitement quand l'application change quelque chose dans son état visuel.

Par exemple, supposons qu'une application déplace un élément dans une fenêtre d'une position A à une position B. Dans la perspective du code de l'application, le changement est immédiat. L'item qui était dans la position A se met immédiatement en B dès que ses coordonnées ont été changées.

Cependant, dans le monde parallèle du moteur de Core Animation, le déplacement de A à B intervient sur plusieurs images et prend un certain temps. Cela signifie qu'il y a une désadaptation temporaire entre l'endroit où l'application considère que l'élément se trouve, et sa place effective sur l'écran. Ce n'est habituellement pas un problème, mais les développeurs sont incités à prendre des précautions pour éviter des effets bizarres (par exemple invalider des contrôles pendant qu'ils se déplacent, et les re-valider quand l'animation est terminée).

Mais c'est le seul effet négatif de cet arrangement. Les bénéfices sont beaucoup plus substantiels. Pour les débutants avec les CPU milticœurs actuels, mettre Core Animation dans son propre thread est une opération gagnante en terme d'utilisation du CPU. Cela signifie aussi que l'application peut aveuglément faire des modifications quand elle veut sans se soucier de l'état d'animations à faire. Par exemple, une application peut déplacer un item de A à B, puis le re-déplacer en C avant que l'animation de A à B soit terminée. Le moteur de Core Animation va sauter les étapes, en déplaçant progressivement l'item vers C, quelle que soit la position entre A et B où il était quand l'application a ordonné son déplacement vers C.

L'absence totale d'implication (pourtant nécessaire) de l'application dans l'animation permet une liberté incroyable. Elle empêche l'application de se retrouver remplie de code centré sur l'animation. Finie la période où les dialogues de préférences avaient 50 lignes de code pour définir et récupérer les préférences, et 200 lignes pour créer des fondus-enchaînés et pour re-dimensionner automatiquement les vitres. Moins de code dans l'application signifie moins de bogues, et plus de liberté pour Apple pour optimiser le tracé réel et le processus d'animation.

L'âge de l'animation commence

Oui, L'arrivée de Core Animation signifie probablement que nous allons avoir à supporter une certaine quantité de logiciels animés sans nécessité, créés par des développeurs enthousiastes à l'excès. Mais la même chose fut vraie pendant l'introduction du texte enrichi, et des graphiques en couleur. Les développeurs sur Mac apprennent vite, et les utilisateurs du Mac excellent à récompenser les retenues et à punir les excès.

La manière minimale, presque humble avec laquelle Core Animation s'intègre à Cocoa cache son incroyable sophistication. Encore plus que pour tout autre nouveau framework dans Léopard, Core Animation fournit des fonctionnalités et des performances qu'il était auparavant difficile ou impossible d'obtenir tout seul pour un programmeur Cocoa moyen. Maintenant, en fin de compte, des applications tierces peuvent apparaître aussi impressionnantes que celles d'Apple, et cela peut être fait en utilisant exactement le même code que celui d'Apple, du code écrit par des programmeurs experts dans le domaine graphique, et continuellement revu et amélioré par Apple pour tirer parti des derniers matériels. Excellent.