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

Mac OS X 10.1




6- Le redimensionnement des fenêtres.

Depuis la livraison de 10.0, presque chaque présentation d'Apple qui concernait Mac OS X a abordé la nécessité d'améliorations de performance, et a mentionné de façon explicite le re-dimensionnement des fenêtres comme élément important, au même titre qu'un meilleur support matériel, ou la nécessité d'applications natives. Cela me trouble que quelque chose d'aussi banal que le re-dimensionnement de fenêtre ait été livré dans 10.0 dans un état aussi terrible qu'il a mérité une mention spéciale dans chaque rapport important de Mac OS X, y compris ceux d'Apple.

La plus mauvaise performance de re-dimensionnement sous 10.0.4 ne concerne rien d'autre que le Finder lui-même. Le redimensionnement d'une fenêtre en liste du Finder fut l'une des premières choses que j'ai essayée sous 10.1.

J'ai été très satisfait quand j'ai vu à quel point il était réactif, même sur le G3/400. Il n'est encore en aucune façon aussi rapide que le redimensionnement de contours (dans Mac OS 8 et X), mais la performance sous 10.0.x était si mauvaise que n'importe quoi proche d'une performance acceptable semble très rapide sous 10.1.

Bien sûr, ce sentiment finit par s'atténuer. Mais la performance de 10.1 est assez bonne pour rendre les vues en liste du Finder à nouveau utiles, et c'est au moins quelque chose. La performance de re-dimensionnement dans toutes les autres fenêtres du Finder s'est aussi améliorée. Le seul problème qui reste est une légère pause avant toute réponse (particulièrement sur les systèmes les plus lents).

Après cette amélioration importante de la performance de redimensionnement des fenêtres du Finder, je me suis précipité pour essayer d'autres applications. Et j'ai été déçu. Les applications autres que le Finder ne semblent pas avoir amélioré de façon significative le redimensionnement des fenêtres depuis 10.0.4 sur un même matériel -même pour les applications qui ont changé depuis 10.0.x- . Le redimensionnement d'une fenêtre IE par exemple, est encore pénible, inutilement lent sur le G3/400. (Il souffre aussi de quelques problèmes secondaires). Et si l'application Mail jointe montre une certaine amélioration par rapport à la version 10.0.x, elle est encore trop lente sur le G3 pour être considérée comme "suffisamment réactive".

Alors, que fait exactement le Finder que les applications ne font pas ? Je n'en suis pas sûr, mais (ce n'est pas étonnant), j'ai mon idée...

En utilisant l'application Quartz Debug dans les outils de développement, (qui affiche en jaune toute portion modifiée de l'écran), J'ai observé que les fenêtres en liste du Finder affichaient en jaune une région correspondant à l'extension de la fenêtre jusqu'aux bords droit et bas de l'écran quelque soit la taille du redimensionnement. L'animation(simulée ci-dessous en fournit un exemple.)

figure

L'initiation de redimensionnement est indiquée par un déplacement de un pixel ou plus dans n'importe quelle direction du widget à re-dimensionner. (Un simple click, et le maintien sur le widget ne provoque pas le flash jaune). Que se passe-t-il ? Pour le savoir, revenons un peu sur l'histoire du redimensionnement des fenêtres sous OSX.

Si on veut évaluer la performance de redimensionnement de fenêtre sous OS X sur la base de chaque démonstration de 10.0.x fournie par Steve Jobs, on ne voit pas de problème du tout. Mais confrontés à la performance désolante de 10.0.X sur leur ordinateur, beaucoup d'utilisateurs de Mac se rendent compte finalement que la raison pour laquelle les démonstrations de Jobs montrent une bonne performance de redimensionnement est qu'il choisit presque toujours de re-dimensionner une fenêtre avec des bonnes caractéristiques, de préférence une image dans l'application Aperçu. Le redimensionnement dans Aperçu est rapide parce qu'il se contente simplement de couper l'image. L'image de la fenêtre existe dans la mémoire qui est allouée quand l'image est chargée. Le redimensionnement de la fenêtre ne fait que révéler (ou cacher) des portions du tampon alloué préalablement.

Je prétends que le Finder, dans Mac OS X 10.1 fait exactement la même chose, mais sur la base d'un changement de dimension. Quand une action de redimensionnement est lancée, je crois que le Finder alloue une seule grande zone d'image remplie par le contenu caché de la fenêtre du Finder le cas échéant, qui s'étend aussi loin (à droite et en bas) que l'utilisateur peut re-dimensionner sa fenêtre, ce qui est la taille exacte indiquée par le flash jaune. (Notez que cette allocation peut aussi expliquer la pause que j'ai observée). Tout mouvement ultérieur de redimensionnement se réduit à une coupure : cacher ou afficher l'image qui a été allouée quand l'action de redimensionnement a été lancée. Et, comme Jobs l'a si bien démontré dans les démos 10.0.x, la coupure est rapide. elle est rapide aussi dans 10.1, et c'est comme ça qu'une fenêtre du Finder se re-dimensionne.

Tout cela n'est que des suppositions, bien sûr. (Les programmeurs d'Apple peuvent se sentir autorisés à me le confirmer). (Et ne vous inquiétez pas, je ne le dirai pas au patron ;-). Mais le Finder doit faire quelque chose de différent des autres applications OS X. D'un côté, l'optimisation peut n'être pas dans le Finder lui-même, mais dans le widget "navigateur de données" sur lequel la vue en liste du Finder se base. Si c'est le cas, toute application qui utilise ce widget peut profiter de cette optimisation.

Quelle que soit la technique utilisée dans le Finder, les autres applications OS X devraient l'adopter, si possible, et revenir à un redimensionnement de contours transparent si une performance acceptable ne peut pas être obtenue. Les développeurs de Word X Test Drive, de Microsoft, une démo de leur version native de Word bientôt prévue pour Mac OS X, semblent avoir les mêmes opinions sur la situation. La fenêtre, dans Word X Test Drive, utilise un redimensionnement de contours à la fois sur le G3/400 et le dual G4/450, et l'expérience utilisateur s'en trouve nettement améliorée.

Si le Finder fait réellement ce que je pense, cette optimisation n'aidera pas toute application qui veut recharger dynamiquement le contenu de sa fenêtre pendant un redimensionnement. Internet Explorer essaie pour le moment de faire cela, avec de très mauvais résultats sur le G3/400, et une performance à peine acceptable sur le G4/450.

En dépit de l'amélioration impressionnante de performance du Finder de 10.1, je crois que ce que j'ai écrit dans mon rapport sur 10.0 s'applique toujours, dans l'ensemble, au redimensionnement des fenêtres sous Mac OS X 10.1 :

Rappelez-vous le but du redimensionnement opaque : un meilleur contrôle visuel, et une meilleure sensation de manipulation. Le redimensionnement opaque de Mac OS X faillit sur ces deux points, et devrait avoir été invalidé si la facilité d'utilisation est le but principal..

Mais d'un autre côté, si vous ajoutez le marketing et la possibilité de faire des démos bluffantes, peut-être que cette caractéristique s'explique mieux. Si je reconnais l'intérêt de ces choses, il faut tracer une limite quelque part. A tout le moins, Apple aurait dû ajouter une option au niveau du système pour invalider le redimensionnement opaque au profit des lignes grisées..

Si Apple est incapable (ou non partisane) de rajouter cette option au niveau du système, c'est aux développeurs à décider quand ils peuvent en toute sécurité implémenter un redimensionnement opaque. Les développeurs de Microsoft pour Mac ont apparemment décidé que le redimensionnement opaque n'était pas prêt pour Word X Test Drive. (On verra en Novembre si la version finale va dans le même sens). Les autres développeurs pour Mac OS X doivent évaluer leurs propres applications, et prendre des décisions, (éventuellement à l'exécution, en fonction du matériel), pour savoir où et quand le redimensionnement opaque est approprié. J'utilise journellement plusieurs applications qui présentent des performances péniblement basses pendant le redimensionnement des fenêtres, et attendent que l'affichage ait atteint le curseur. C'est mauvais.

Si les améliorations de performance pour le redimensionnement du Finder sont très bienvenues, le problème n'en reste pas moins, et ne disparaitra pas tant les développeurs d'applications (y compris ceux d'Apple) n'auront pas commencé à prendre des décisions sur l'usage effectif du redimensionnement opaque, plutôt que sur la performance attendue, ou sur l'effet de marketing. Le redimensionnement des fenêtres n'est pas une caractéristique de haut niveau. Il est aussi basique que le fait de fermer une fenêtre ou de sélectionner une icône. Le redimensionnement de fenêtre doit se comporter à peu près à la perfection sur tout système sur lequel Mac OS X peut fonctionner. S'il ne peut pas être opaque, qu'il en soit ainsi.