Aucun souvenir de mes cours d’allemand, donc je ne saurais dire ce que signifie le titre, mais l’essentiel n’est pas là : magnifique site pour Audi, Site of the day par The FWA

Pratique d’ActionScript 3 - Janvier 2009
4 Commentaires Publié le 19 novembre 2008 _ Communauté, Documentation
Repoussée, puis annulée, la publication du livre de Thibault Imbert virait au cauchemar.. A l’initiative de l’auteur, la mise à disposition gratuite sur le site de l’auteur, Pratique d’ActionScript 3, a connu un grand succès, et c’est avec un grand plaisir que celui ci nous annonçait que Pearson allait finalement publier son livre.
Il devrait être publier en janvier 2009.
Vous pouvez être tenu au courant de la disponibilité du livre sur la page dédié du site de l’éditeur.
On croise les doigts pour que la publication aille jusqu’au bout, et que le livre soit un succès !
via envrac.org »
Comparatif Moteurs 3D, et le plus performant est…
18 Commentaires Publié le 18 novembre 2008 _ 3D, DéveloppementSuite aux derniers posts concernant les moteurs 3D ( Alterntiva3D, Away3D, Papervision3D & Sandy3D), j’ai fait quelques tests afin de comparer les temps de création d’objet (Cube, Sphere, Cône et Plane) dans chacun des moteurs.
Attention, suite aux dernières mises à jour du framework de Papervision3D, les problèmes de mémoire évoquer ci-dessous n’ont plus lieu d’être.
Comparatif à jour & complémentaire ici »
Mise à disposition des sources :
- Alternativa3D » (le framework n’est pas inclus, n’étant pas en open-source)
- Away3D »
- Papervision3D »
- Sandy3D »
Ma méthode fut la suivante :
- Implémentation au plus simple et identique pour chacun des moteurs.
- Mécanique identique de création des objets, instance unique.
- Une seule instance des materials ( filaire et texture )
- Utilisation de calcul asynchrone afin de ne pas avoir de valeurs faussés ( la création de l’objet est faite quand le processeur le permet )
- Test à la création de 1000 objets, avec différentes variables ( filaire ou bitmap, lissage de l’image ou non)
- Stockage des données dans un tableau, les résultats utilisés sont les moyennes de temps de création et de mémoire utilisés par objet.
- Vérification de la mémoire initiale, du pique de mémoire, ainsi que de la mémoire utilisé après les tests.
Version :
- Papervision3D : Public Beta 2.0 - Great White / 2008.09.09 (revision 731)
- Away3D : 2.1.0 / 2008.05.23
- Sandy3D : 3.0.2 / 2008.02.25
- Alternativa3D : 5.3.0 / 2008.08.12
Comme vous pourrez le remarquer les résultats sont très disparates suivant les moteurs, et même si les objets n’ont pas les mêmes caractéristiques (le nombre de segments d’un cube ne peut pas être augmenté dans Away3D & Sandy3D, contrairement à Alternativa3D & Papervision3D), les différences parlent d’elles mêmes… Vous le verrez dans les 4 points suivants :
1. Poids SWF
L’exportation du fichier swf et le poids de celui ci (non négligeable au moment de l’accès au site, notamment pour les petites connexions) montre les premières différences entre les moteurs.
Le premier cas importe les package de camera, vue et scene.
Le second cas importe en plus les pacakge de Cube, Plane, Cone et Sphere.
| - | |||
| 1. Sandy3D | - | ||
| 2. Alternativa3D | - | ||
| 3. Papervision3D | - | ||
| 4. Away3D | - |
2. Mémoire à l’initialisation du moteur:
Voyons maintenant l’espace mémoire pris lors de l’implémentation du moteur 3D. On test la mémoire sans lancer aucune création d’objet, et les moteurs montrent déjà que certains sont plus optimisés et d’autres, beaucoup, beaucoup moins :
1. Papervision3D - 167 ko
2. Away3D - 199 ko
3. Alternativa3D - 202 ko
4. Sandy3D - 1 136 ko
Sandy3D part donc déjà avec un gros handicap, on verra par la suite que ce n’est pas le seul…
3. Mémoire Globale:
L’écart se creuse encore, Papervision3D et Sandy3D ont une très mauvaise gestion de la mémoire, en effet malgré la suppression de l’objet sur la scène et de son instance, il est toujours en mémoire. L’application monte donc en mémoire, sans jamais redescendre, ce qui peut s’avérer extrêmement dangereux… Il est à noté que Away3D & Alternativa3D gèrent par contre très bien la mémoire, et suppriment les éléments comme il faut. Après la création de plusieurs milliers d’instance de plusieurs objets, on se retrouve avec une mémoire :
1. Away3D - 700 ko
2. Alternativa3D - 876 ko
3. Papervision3D - 50 784 ko
4. Sandy3D - 175 552 ko
Les graphes ci-dessous montre bien la gestion de la mémoire par les 4 moteurs 3D, on remarque sur Alternativa3D & Away3D, la mémoire qui évolue suivant les suppressions d’éléments et le lancement du Garbage Collector, alors que pour Papervision3D & Sandy3D, ca monte, ca monte, ca monte….
Alternativa3D

Away3D

Papervision3D

Sandy3D

4. Création d’objet :
Question de logique, plus l’objet à créer est compliqué, plus il faudra de temps pour le créer, et plus la mémoire utilisé par cet objet sera importante… Comparer les temps de création et d’espace mémoire entre chacun des moteurs objets est assez compliquer. En effet, malgré des valeurs identiques, les moteurs créer des objets plus ou moins complexes, je ne comparerais donc pas la forme de ces objets, le nombre de triangle étant assez identiques, l’appréciation de la qualité de l’objet est spécifique à chaque utilisateur…
|
Création d’un objet filaire
|
||||
| Box | Plane | Cone | Sphere | |
| Away3D | 0.814ms - 23ko | 0.321ms - 9ko | 1.265ms - 37ko | 4.884ms - 138ko |
| Alternativa3D | 5.865ms - 95ko | 1.913ms - 20ko | 5.723ms - 102ko | 9.434ms - 179ko |
| Papervision3D | 4.961ms - 126ko | 0.872ms - 23ko | 2.996ms - 76ko | 4.126ms - 84ko |
| Sandy3D | 1.645ms - 16ko | 0.267ms - 12ko | 10.848ms - 222ko | 15.299ms - 314ko |
|
Création d’un objet avec bitmap non lissé
|
||||
| Box | Plane | Cone | Sphere | |
| Away3D | 1.292ms - 35ko | 0.817ms - 23ko | 1.67ms - 49ko | 5.159ms - 153ko |
| Alternativa3D | 5.909ms - 96ko | 1.966ms - 21ko | 5.733ms - 102ko | 9.478ms - 178ko |
| Papervision3D | 6.486ms - 169ko | 1.801ms - 70ko | 3.607ms - 121ko | 5.31ms - 130ko |
| Sandy3D | 1.856ms - 18ko | 0.254ms - 12ko | 11.389ms - 229ko | 16.295ms - 330ko |
|
Création d’un objet avec bitmap lissé
|
||||
| Box | Plane | Cone | Sphere | |
| Away3D | 1.319ms - 35ko | 0.843ms - 23ko | 1.722ms - 51ko | 5.195ms - 152ko |
| Alternativa3D | 5.811ms - 97ko | 1.954ms - 21ko | 5.764ms - 102ko | 9.475ms - 182ko |
| Papervision3D | 6.391ms - 169ko | 1.837ms - 70ko | 3.556ms - 121ko | 5.259ms - 128ko |
| Sandy3D | 1.747ms - 18ko | 0.221ms - 12ko | 11.16ms - 228ko | 15.657ms - 330ko |
4.1 Temps
De manière globale, Away3D est le plus rapide.
Sandy3D a des performances équivalente voire meilleure pour la création de Box ou de Plane, mais est très très loin d’être aussi performant dans la création de Cône ou de Sphère, une fois de plus celui ci se démarque par sa singularité.
Quelque soit le type de texture utilisé, Alternativa3D a des temps de création quasi similaires, il est donc moins performant lors de création d’objet filaire, mais cet handicap se réduit donc lors de la création d’objet “texturé”.
Les temps de création d’objet par Papervision3D se situe dans la moyenne de celle d’Away3D et Alternativa3D, excepté pour les Box, ceci étant du aux nombres de segments crées par Papervision3D.
1. Away3D
2. Papervision3D
3. Alternativa3D
4. Sandy3D
4.1 Mémoire
Comme pour les temps de création, Away3D est le moins gourmand en général :
- Sandy3D consomme moins de ressources lors de la création de Box ou de Plane, mais explose littéralement lors de la création de Cône et de Sphère
- Papervision3D, consomme beaucoup moins de ressource lors de la création de Sphère, mais utilise presque 6 fois plus de mémoire qu’Away3D lors de la création de Box ( notamment du, comme pour le temps de création, au nombre de segments crées par Papervision3D )
Alternativa3D est quant à lui dans la moyenne haute des autres moteurs, sans pour autant être catastrophique.
1. Away3D
2. Papervision3D / Alternativa3D
4. Sandy3D
Différence de temps de création entre un objet filaire et un objet texturé :
| Box | Plane | Cone | Sphere | |
| Away3D | +/- 0.5ms | +/- 0.5ms | +/- 0.5ms | +/- 0.3ms |
| Alternativa3D | +/- 0.1ms | +/- 0.1ms | +/- 0.1ms | +/- 0.1ms |
| Papervision3D | +/- 1.5ms | +/- 1.0ms | +/- 0.7ms | +/- 1.2ms |
| Sandy3D | +/- 0.1ms | +/- 0.1ms | +/- 0.5ms | +/- 1.5ms |
Ces écarts de temps de création sont à corrélés avec la mémoire utilisés par la création de cet objet :
| Box | Plane | Cone | Sphere | |
| Away3D | +/- 12ko | +/- 14ko | +/- 13ko | +/- 14ko |
| Alternativa3D | +/- 1ko | +/- 1ko | +/- 1ko | +/- 3ko |
| Papervision3D | +/- 43ko | +/- 47ko | +/- 45ko | +/- 46ko |
| Sandy3D | +/- 2ko | +/- 2ko | +/- 6ko | +/- 15ko |
On peut remarquer que ces écarts sont quasi idem pour chacun des objets crée par chaque moteurs 3D, Alternativa3D ayant un delta proche de zéro, on peut conclure que la gestion de texture filaire ou bitmap se fait de la même façon. On remarque aussi les différences de delta pour Sandy3D entre les objets Box/Plane et Cône/Sphère.
5. Conclusion
Les tests effectués ne sont peut être pas représentatifs de la création d’une application, ou d’un site internet, mais ils nous montrent comment réagissent ces moteurs 3D dans des cas extrêmes, et si certains cas semblent dangereux (notamment la gestion de la mémoire), il faut garder en mémoire que tout le monde n’a pas de machine surpuissante, et qu’il faut toujours penser à qui est destiné le développement que l’ont fait (et pas se dire, si ca marche sur ma machine, y’a pas de raison que ca marche pas ailleurs, comme je l’entend assez souvent…).
De plus, ce comparatif ne prend pas en compte les différentes possibilités offertes par certains moteurs 3D (réélections…), il faut donc choisir judicieusement le moteur en fonction de ces possibilités ainsi que de ces performances.
Concernant les performances, venons en donc aux conclusions.
4. - Sandy3D et la mémoire, ce n’est pas un histoire d’amour, et ce, dès l’initialisation du moteur, et même si les performances lors de la création de Box et de Plane sont parmi les meilleures, la gestion de la mémoire (pas de suppressions des instances), les performances “catastrophiques” pour la création de Cône et de Sphère (donc d’éléments complexes), montrent les lacunes de Sandy3D. Au vue des résultats, c’est le seul moteur qui ne réagit pas de façon homogène, si vous l’utiliser il faut rester dans des formes simples, et peu nombreuses…
2. ex aequo - Les temps de création de Papervision3D se situe dans la moyenne, c’est au niveau de la mémoire que ça se gâte, malgré une bonne gestion lors de la création de Sphère, il est bien plus gourmand lors de la création de Box et de Plane. Nous avons pu voir que Papervision3D ne supprime pas ces instances et rencontre donc le même problème que Sandy3D, sans pour autant cumuler au même sommet mais c’est à surveiller lors de création et suppression de nombreux éléments…
2. ex aequo - Alternativa3D, dernier venu dans le monde des moteurs 3D, gère extrêmement bien (ou plutôt normalement !?) la mémoire, il est cependant plus gourmand en temps de création (entre 2 et 5 fois plus) que les autres moteurs. Malgré son coup de licence qui peut freiner, ces performances en font un des meilleurs moteurs 3D actuels.
1. Et pour finir, Away3D. Temps de création les plus bas du comparatifs, mémoire nécessaire à la création les plus bas aussi, excepté sur quelques points (Box et Sphère), mais qui reste excellents, et gestion de la mémoire globale excellente aussi. Bref le moteur 3D que je conseillerai (en terme de performance, encore une fois, et pas de possibilité de rendu graphique ).
Merci à Philippe, dit “Papa”, pour sa relecture !
NB:
- Comparatif réalisé avec le Flash Player 10
- J’ai utilisé le terme Box de façon générale, la classe exacte pour Away3D et Papervision est Cube, il en est de même pour Plane3D dans Sandy3D
Tout juste annoncé au Adobe MAX 2008 à San Francisco, le projet connu sous le nom de code Thermo devient donc Adobe Flash Catalyst et devrait pointer son nez, en version beta, en début d’année prochaine. Adobe nous promet un outil qui révolutionnera la création d’application graphique, notamment sous Flex, avec plus de facilité, à partir de Photoshop CS4, Fireworks CS4 ou Illustrator CS4.
La page Adobe Flash Catalyst sur labs.adobe.com »
Le blog de Flash Catalyst (avec quelques leçons pour débuter, pour ceux qui ont une version pre-release) »
3 Méthodes pour réduire le poids d’une application Flex
0 Commentaire Publié le 17 novembre 2008 _ Développement, FlexSerge Jespers nous présente sur Adobe TV, 3 méthodes pour réduire le poids d’une application Flex.
Pour résumer :
- Exportation de l’application en Release
- Utilisation de MXML Module (création de swf externe)
- Framework Flex externe (Librairy Path > Framework linkage > Runtime shared library - RSL)
L’explication complète en vidéo :
Parmi les nouveautés de Flash10, les restrictions de sécurité du FileReference font parties des mauvaises nouvelles. Bien que sur le papier l’enjeu sécuritaire est important, le fait qu’il n’y ai pas de rétro compatibilité pose pas mal de problème et la blogosphère de développeurs Flash/Flex le montre bien :
Flex and Flash Developer - Jesse Warden dot Kizz-ohm
The Flash Blog
En effet, dans le Flash Player 10, l’appel à Filereference.browse ou FileReference.download n’est accepter que lorsque qu’il y a une action utilisateur (MouseEvent, KeyboardEvent…), si cela pose quelques problèmes pour les nouveaux projets à venir (utilisation d’un framework utilisant les notifications, donc appel indirect…), cela en pose encore plus pour les anciens projets, qui pourront ne plus fonctionner suivant la méthode de développement utilisés.
Je me suis confronté au problème sur un projet Flex / PureMVC, suite à un clic utilisateur, j’appelle à un webservice qui me renvoi l’adresse d’un fichier à télécharger, je lance alors un FileReference.download(), mais Flash10 ayant “perdu” l’action de l’utilisateur dans les notifcations de PureMVC, il fait une alerte :
Pour l’utilisateur ayant Flash10, rien ne se passe, et malgré de nombreuses tentatives ( ce que ferait n’importe quel utilisateur dans ce cas) l’utilisateur ne pourra jamais effectuer l’action voulu. Donc tous vos développement antérieurs faisant appel à une méthode de FileReference indirectement ne fonctionera plus sur Flash10, il vous faudra reprendre vos anciens projets, se replonger dans le code, et résoudre ce problème !
La solution étant la suivante :
try {
// Flash Player 9
_file.download(new URLRequest(url));
} catch(erreur:Error) {
// Flash Player 10
popupFlash10(url);
}
On test si l’appel à la méthode download de FileReference fonctionne (Flash 9), si ce n’est pas le cas (Flash 10), on ouvre une popup proposant le lien à l’utilisateur, qui valide en cliquant sur un bouton.
Flash 10 détectant l’appel à la méthode download de FileReference par une action utilisateur, le téléchargement fonctionnera…
Upload et Download requert un action utilisateur ( Adobe Flash 10 security changes ) »
Parmi les mises à jours du 17 novembre sur labs.adobe.com, la prerelease 5 de Pixel Bender.
Au menu de cette mise à jour, le réglèment de quelques bugs, le plugin pour Photoshop CS4 et une documentation complète (Developer’s Guide & Reference).
Les nouveautés de la prerelease »
Télécharger Pixel Bender Toolkit & le plugin Photoshop CS4
|
RechercheCatégories
|
||
