jeudi 24 mars 2011

Quelle technologie RIA pour mon Application web ?

Internet prend une place de plus en plus importante dans nos habitudes de consommation des médias au point qu'aujourd'hui les applications elles même sont déportées sur le net. Attention cependant toute application ne peut pas être adapté en webapp. Pourquoi ? Parce que le web n'offre pas les même possibilités de rendu, de performances, ni même d'animation pour les IHM. Pour une application présentant des données, permettant une saisie et affichant quelques graphiques, la web app est toute indiquée. Pour les applications plus gourmandes un autre choix s'impose, je vous invite pour cela à lire ce billet : Client Riche, Léger ou Lourd ?

Quelles sont les solutions qui se présentent à nous dans la réalisation de logiciel dit Client Léger ou Client Riche en ligne ?

Solution 1 : Pur Javascript

Vous pouvez tout à fait programmer votre interface en pur HTML / Javascript. Cela à le mérite d'être rapide à mettre en place et de s'affranchir de l'apprentissage des langages plus complexes que sont Java ou ActionScript 3. Pour cela, l'Ajax sera de rigueur, vous connaissez surement cette technique qui permet de mettre à jour les données d'une page sans avoir à recharger celle-ci. Sinon jetez un coup d'oeil ici. Grace à l'Ajax, le javascript à prit une place prépondérante dans le développement web. Aujourd'hui il existe de nombreux frameworks javascript qui permettent de réaliser de bout en bout une interface graphique. Je siterai par exemple Jquery (Mootools, Prototype que je n'ai pas manipulé) ainsi que Ext-js qui est une librairie absolument phénoménale bourrée de composants graphiques complexes très utiles.

Le javascript étant un langage de script ( comme son nom l'indique ), coder une interface complexe peu vite s'avérer lourd tant au niveau de la structure de l'application qu'au niveau du debuggage. Des outils comme Backbones.js existent pour tenter de structurer un peu le code, mais globalement je vous conseille de coder vos webapp en javascript que si elles restent de taille relativement modeste. Pour ma part je suis resté sur un design en HTML / CSS sans passer par un framework pour le coté graphique. Le fait de pouvoir designer ses composants comme on le fait quand on réalise un site web offre une liberté très appréciable. Je n'ai du coup utilisé le javascript que pour rapatrier les données, rafraichir l'interface et faire quelques animations, par le biais de Jquery qui offre une syntaxe très concise.

Exemple d'application HTML / Javascript avec un graphisme "fait maison"


Solution 2 : Flex

Flex est une technologie qui a eut un rôle précurseur dans le monde des RIA. Issue de la technologie Flash, elle a longtemps été regardée de manière incomprise par le monde des Flashers qui ne comprenaient pas l'intérêt de cette nouvelle plateforme. L'idée est pourtant simple, se servir du player Flash, présent sur 95% des ordinateurs pour afficher des interfaces aussi poussées que celles des logiciels type Client Lourd. Flex offre l'avantage par rapport à d'autre technologies de s'exécuter dans une machine virtuelle ce qui l'affranchie de toute contrainte liée aux langages web courant ( HTML , et Javascript ). La force de Flex réside dans ce que cette technologie hérite de son cousin Flash à savoir un environnement permettant la réalisation de composant riches et soignées, une réactivité et une capacité d'animation poussée. Néanmoins l'environnement Flash pèse lourd, et l'exécution d'une application Flex peut parfois s'avérer douloureuse pour le processeur. De plus la technologie Flash n'étant pas un standards mais la propriété de la société Adobe, elle tend à s'effacer face au couple HTML5 / CSS3 / JavaScript plus ouvert et de plus en plus impressionnant. En définitive Flex doit s'imposer à vous pour les besoins qui nécessite que vous fournissiez une interface extrêmement soigné et personnalisée, où l'animation et le sens du détails ont une importance capitale. A noter que le Flash, donc Flex ne s'exécute pas sur les terminaux d'Apple ce qui est bon de se rappeler :)

Flash Builder, un outils bien sympa ( mais payant ) pour concevoir vos interfaces en Flex


Solution 3 : JavaFX

JavaFx, j'en parle juste parce que c'est une technologie qui à fait du bruit. Pour moi c'est un flop, un raté total, instable et bourré de bugs. Si j'en parle, c'est simplement pour que vous le l'envisagiez pas. Du moins pas pour l'instant, Oracle semble s'être rendu compte de l'état du projet et compte faire le ménage dans tous ça. En espérant qu'ils nous livrent une techno intéressante cette fois.

Solution 4 : Silverlight et .Net

Pendant un temps le grand concurrent de Flash / Flex, microsoft semble avoir mis un frein sur cette technologie au profit de HTML5. Pourtant Sliverlight s'avère convainquant notamment pour la question des performance et dans la gestion de la vidéo. La gestion du lissage des textes est cependant perfectible. Je ne sais quel avenir attend Silverlight, certain outils comme Expression Blend permettent des rendu impressionnants, mais l'aspect libre du HTML5 semble prendre les devants.

J'omet au passage de parler des solution basé sur l'environnement .Net de Microsoft et Mono son implémentation libre, car je ne les connais tout simplement pas :D Si vous avez travaillé sur cet environnement et que vous souhaitez en faire par laissez un commentaire ;)

Solution 5 : GWT

Pour moi GWT est l'arlésienne des frameworks Client Léger. C'est pour moi la solution qui s'impose le plus souvent. Pourquoi ?

Les performances : GWT c'est rapide. Pour peut que l'on aime mettre les main dans le cambouis il est possible de monter à un haut niveaux d'optimisation. Découpage du code en briques téléchargée à la demande, environnement de test complet, cache des données en local...

L'architecture du framework : Plus on passe de temps à utiliser GWT, plus on se dit que c'est bougrement bien conçut. GWT a su s'inspirer de Flex pour créer des interfaces déclarative en xml. Il reste néanmoins possible de programmer son IHM comme on peut le faire en swing. GWT gère l'historique du navigateur, le pattern mvp ( Model View Presenter ) bien que complexe à aborder induit une logique implacable dans la structure de votre application.

Bref vous l'aurez compris GWT ça déchire :) Néanmoins il faut quand même garder à l'esprit 2 choses : GWT s'adresse avant tout à des développeur maitrisant Java EE ( attention Java != JEE ). L'avantage de cette techno est de pouvoir aisément se synchroniser avec des services web codés en java pour se passer des objets comme si la partie client et serveur étaient regroupées. Il reste tout de même possible de se passer des informations de manière traditionnelle avec des requêtes pour se connecter à des services écris dans un autre langage.

Globalement le framework reste plus difficile à aborder que Flex, il fait appel à des patterns que l'on aborde lorsque l'on a un niveau ingénieur. Néanmoins lorsque l'on est familier avec ces patterns ( ou qu'on apprend à l'être comme moi ) on remarque que le tout est très structuré et extrêmement bien adapté aux applications de taille conséquente.

Mais au fait, GWT c'est quoi ? GWT est un framework qui fourni simplement un écosystème familier pour tous développeur Java habitué à coder du Client Lourd en Awt, Swing ou Swt et qui souhaite développer une application web. A ceci près qu'il s'adapte aux contraintes techniques imposées par la génération de contenu web, et met en place une architecture orientée vers la productivité et les performances. Concrètement comment fait GWT pour créer une application web codé en Java ? Tout le code généré coté client, celui qu'interprète votre navigateur est du pur Javascript / HTML / CSS. Le code java est compilé en javascript et optimisé. Du coup cela permet au développeurs Java de coder une IHM sans avoir à apprendre les langages web. GWT étant parfaitement intégré à l'environnement Eclipse, des fonctionnalités comme le debuggage, l'autocomplétion sont très appréciable en plus de bénéficier de la structure d'un projet Java.

Une GUI basique en GWT


GWT n'est cependant pas parfait, en effet, de base il n'intègre pas autant de composants ni de fonctionnalités que Flex. Il vous faudra donc créer vos propres composants.

Autre solution : Vous n'avez pas le temps de développez de composants et avez besoins de widgets prêts à l'emplois. Alors vous vous tournerez surement vers les bibliothèques tierces comme smartGWT ou Ext-GWT ( alias gxt a ne pas confondre avec gwt-ext qui est un projet mort). Je vous recommande cette dernière qui fournit des composants de très bonne qualité et de bien meilleures performances que SmartGWT. A noter que ces implémentations ont généralement 1 an de retards sur GWT, le temps d'implémenter les nouvelles fonctionnalités. GXT 3.0 qui devrait sortir courant 2011 semble combiner le meilleur des 2 mondes : la richesse des composant de la librairie Ext et la puissance de la structure de gwt (mvp, uibinder…).

Une interface réalisée avec Ext-GWT


Voici donc un tour d'horizon ( basique ) des technologies RIA du moment. J'en ai omise certaines ( Echo2, IceFaces, OpenLazlo… ) car ce serait trop long et de toute façon je ne les connait pas ^^ N'hésitez pas à poser vous commentaires si vous utilisez une des techno citées ou si simplement vous avez des questions.
Bon codage :)

samedi 19 février 2011

Petites nouvelles d'un blogeur disparu

Voila un mois que je n'ai rien posté, mais que ce passe t'il donc ? Nouveau job, nouvel emploi du temps, du coup mon blog est un petit peu délaissé. Dorénavant les billets de ce blog vont prendre une orientation un peu plus hardcode. Et oui, j'ai troqué le monde du Flash, du PHP et du graphisme pour celui de Java. Bon, bien sur, on ne change pas un homme comme ça, et je conserve tout de même beaucoup d'intérêt pour le web son rôle de précurseur sur la définition des interfaces de demain. Mais pour aujourd'hui il est temps de faire une petite mise à jour du coté fonctionnel, et je peu vous dire que venant du web, ça fait drôle ! La taille des projets n'est pas la même, cela m'a impressionné de voir un projet constitué de vingtaines de fichiers à leur tour encapsulés dans des dizaines de dossiers. Il me faut donc acquérir dans un laps de temps assez cours beaucoup de notions comme les design pattern, les outils de déploiements, le mappage objet - relationel, la persistance des objets. Et oui, l'univers JEE est bien différent de celui du web, et j'y consacrerai bientôt un parallèle pour que cet univers soit un peu mieux compris par les développeurs web.

Alors un premier bilan après deux semaines à manger du Java ? Java est un langage que je connaissais bien, mais l'implémentation de ce langage pour les entreprises, JEE (Java Entreprise Edition) demande beaucoup plus de compétence que le langage à lui seul. Ce que je peu vous dire c'est que travailler dans un environnement JEE est très formateur. Java étant un langage assez bien foutu et plus haut niveau que le C/C++ il est possible de se concentrer d'avantage sur l'architecture de votre application plutôt que sur la gestion de concepts bas niveau comme la gestion de la mémoire. Et au niveau de l'architecture on voit que les grosses têtes de ce monde se sont amusés à créer des structures assez poussées. J'explore pour l'instant les plus basiques mais je doit avouer que je me régale. Au menu EJB3, Hibernate et GWT qui est une techno dont je parle depuis un bon moment et qui est très prometteuse. Pour plus tard j'espère pouvoir concilier la complexité des services que permet Java sur le serveur, avec des interface léchés, complexes et fonctionnelles coté client. Je vous tiens au jus ;)

vendredi 21 janvier 2011

Comment stimuler sa créativité

Rendez vous compte qu'hier soir j'ai eu une illumination, et oui ! Alors que ma créativité est au plus bas dans cette période de stress professionnel, j'ai réussi à la retrouver, elle qui était si présente jadis. Bon je vous vois enjoué, j'en fais surement un peut trop. N'empêche que voici une astuce qui saura surement trouver son public.

Tout d'abords c'est assez rageant lorsque l'on fait un métier créatif de voir que l'on a pas toujours la maitrise de notre créativité. Elle vient au grès du vent ou de son bon vouloir. Le processus créatif est quelque chose qui nous échappe. Ce n'est pas une compétence facile à apprivoiser et elle ne répond pas toujours aux mêmes logiques que la connaissances. Bref on ne sort pas une idée comme on sort une citation de Baudelaire :)

Le processus créatif repose dans le subconscient ( je ne suis pas expert, mais si il y en a un ici qu'ils s'expriment ). On peut essayer de former une idée à partir de concepts que nous avons déjà aperçu et en touillant bien fort pour voir ce qu'il en ressort. Pour ma part il s'agit bien (trop) souvent d'idées chimériques.  Bref le processus normal de créativité est un peu comme une roulette russe, on ne sait jamais sur quoi l'on va tomber, des bonnes idées, des mauvaises, des clones d'autres idées.

Alors ou je veux en venir ?  Et bien, si la créativité est de l'ordre de l'inconscient, alors il faut aller chercher ses idées... dans l'inconscience. Qu'est ce que cela veut dire ? Non, je ne vous inciterai pas à vous rendre ivre, ni même de travailler sous exta. Je me veux le promoteur d'une méthode plus douce : le sommeil.

Ou plutôt l'avant sommeil, parce que une fois que l'on dors on est bien loin de nos soucis de travail ^^ Cette phase ou l'on se sent partir est l'instant clé. C'est le moment ou votre pensée laisse inconsciemment place à une réalité que vous avez imaginé. Essayer pendant cet instant de lutter, de vous raccrocher à la réalité et pensez à l'idée en question que vous aimeriez avoir. Jamais vos idées ne vous auront parut si apparente, si accessible, et même si crédible. Et elles le sont ! Si vous n'y parvenez pas directement, pensez au contexte, imaginez les éléments qui gravitent autours puis attaquez vous à ce que vous devez créer. Vous verrez que dans votre imaginaire cette part inexistante dans le réel l'est dans votre subconscient. Prenez toujours de quoi noter à proximité de votre oreiller, un bloc note, pour ma part mon iphone fait bien l'affaire même si je sais qu'a terme il m'aura grillé le cerveau.

Alors oui, c'est la tout le secret. Tout ça pour ça ? Me direz vous. Tentez l'expérience et vous verrez que ce simple principe a de la valeur. N'hésitez pas à me faire vos retours, à me traiter de charlatan si vous le souhaitez ^^ Je vous souhaites à tous de bonne séances de sommeil créatif.

lundi 17 janvier 2011

Animer un décor avec un travelling en html et javascript (jquery)

Vous avez déjà pensé à réaliser un travelling pour votre site, mais l'idée vous à paru trop complexe, trop gourmande en ressource, ou bien vous vous sentiez obligé de passer par flash? Que néni ! Réaliser un travelling en plein écran c'est facile ! Et cela se prête à plein d'utilisations possible. Que ce soit comme animation d'arrière plan, ou dans le cadre d'une interactivité poussée, il est aujourd'hui aisée de faire un travelling avec Javascript.

J'utilise personnellement la librairie Jquery, qui permet d'animer des éléments du DOM avec une simplicité déconcertante. Mais alors, comment fait on ? C'est le sujet de ce micro tutoriel.

Pour bien faire il faut créer une structure basique pour son site avec quelques balises div. Les div sont des conteneurs qui par défaut se positionnent les un en dessous des autres. Ici il n'est point question de se prendre la tête avec le placement de ces div. Il n'y en a que deux ! Le premier div est en fait un conteneur global, c'est à l'intérieur de celui-ci que va se produire l'animation du travelling. Son rôle est de créer une zone de visibilité (ici égale a la taille totale de la fenêtre).
Voici son style css : 

position:absolute; /* le bloc aura une position fixe */
width:100%; /* il occupera toute la largeur de la fenêtre*/
height:100%; /* ainsi que toute sa hauteur */
overflow:hidden; /* tout ce qui dépassera les dimension de la fenêtre sera masqué, et il n'y aura pas d'ascenseur */

A l'intérieur nous y trouverons un autre div, celui qui contiendra directement l'image de background. C'est ce div qui sera animé et qui donnera l'impression de travelling.
style css : 

position: relative /* nécessaire pour que l'animation fonctionne */

A l'intérieur de ce div, nous insérerons notre image, avec la balise img. L'image que vous placerez devra avoir une longueur conséquente (la mienne fait 2560 de long soit le double de ma largeur d'écran).

Voila rien de plus pour les éléments, si on récapitule nous avons 2 blocs et une image. Chacun étant imbriqué dans l'autre ce qui nous donne quelque chose comme ceci : 

div
div
img
/div
/div

Voila, je vous conseille également de mettre ce style à votre body{
margin:0;
padding:0;
}
Cela évitera qu'il y ai des bordures noires sur les cotés de votre navigateur.



Maintenant place à l'animation !

L'animation va se faire grâce à un tout petit script Jquery. Je vous conseille de jeter un coup d'oeil à cette librairie javascript qui recèle de petites astuces bien sympa.

Dans un premier temps, il faut bien sur que vous télécharger le .js de jquery, et que vous le rangier bien soigneusement non loin de votre page html pour pouvoir y accéder avec la balise script type="text/javascript" src="js/jquery-1.4.4.js"

Voici ensuite le code javascript qui fera bouger votre décors ( à taper à l'intérieur de balise script bien sur ) : 

$(document).ready(function(){
jQuery.fx.interval = 20;

$('#bkgd').animate({
   left: '-=100%'
}, 2000);
});

Ahhh qu'est ce que cela veut dire (pour les non initiés ;p )

jQuery.fx.interval = 20; /* question de performances, je limite le nombre d'images par secondes à 50 img/sec (1000/20 = 50)*/

$('#bkgd').animate est la méthode qui permet d'animer en Jquery, ici nous allons demandé à notre bloc div contenant l'image, et dont la propriété id est égale à "bkgd" de translater vers la gauche, l'équivalent de la largeur de la fenêtre du navigateur : left: '-=100%' en 2 secondes.



Voilà alors bien sur, cette explication n'est que le décriptif de toute cette opération, et il se peut que vous ne réussissiez pas à faire un travelling fonctionnel avec ça, sinon c'est que vous êtes bon et tant mieux pour vous :p

Je vous invite donc à jeter un coup d'oeil aux sources, et à vous rendre compte par vous même du type de rendu que l'on peut obtenir. Bon courage

jeudi 6 janvier 2011

Informatique Client Léger, Riche ou Lourd?

A qui s'adresse cet article? Aux débutants en programmation ou ceux qui se posent la question de ce qu'est ce charabia à propos des clients léger, lourd ou je ne sais quoi...

L'informatique évolue constamment les pratiques qui en découlent aussi. Hier l'informatique ne passait que par les lignes de commandes, puis sont apparues les première interfaces graphiques qui ont décuplés le potentiel de l'outil  l'informatique. Sont apparuent avec les nouveaux usages de cet outil les notions d'ergonomie et d'esthétique. Des notions sur lesquelles je ne m'attarderai pas. En effet pour ce billet je vais plutôt aborder le coté fonctionnel de l'informatique. Au cours de la conception d'un projet informatique plusieurs notions reviennent fréquemment. Les technologies employées, les langages, et les infrastructures. C'est sur cette dernière notion que je vais m'attarder. 

On peut distinguer 3 types d'infrastructures, les clients dit "Lourds" qui sont des logiciels dont tous les services s'exécutent sur le poste client. Les clients "Riches" qui, eux s'exécutent sur le poste client mais dont une partie du fonctionnement est déporté sur un serveur distant. Et enfin les clients "Légers" qui sont eux entièrement déporté sur le serveur, l'interface n'est pas stockée sur le poste client et le rendu de l'application est généré en fonction des données qu'envoi le serveur.

Voici brièvement les 3 grands types d'infrastructures possibles. Alors, pour mon application, quel type d'infrastructure dois-je adopter? Comme vous avez pu le constater, il n'y a pas d'infrastructure surclassant les autres. Tous est affaire de besoins, et ce sont ces besoins que nous allons étudier en détails.

Le Client Lourd 

Si votre application ne nécessite pas de connexion à un serveur distant, c'est qu'à priori elle se suffit à elle même. Contrairement à un lecteur de flux RSS votre application ne nécessite pas de mise a jour fréquentes. Dans ce cas là le Client Lourd est tout indiqué. Avec le client Lourd vous aurez l'avantage de pouvoir faire une application mieux intégrée à l'OS, à condition de bien choisir son framework. Bien souvent il vous faudra choisir entre portabilité et intégration au système/ performances. Les application natives tirent mieux parti de la puissance de calcul de la machine. Qu'est ce que cela signifie? Si votre application nécessite une puissance de calcul importante, pour lire ou encoder une vidéo par exemple, ou afficher des modèles 3D, vous vous tournerez plutôt vers les librairies de votre OS. Le langage le plus utilisé dans ce cas est le C/C++. Si la puissance vous importe peu, et que la portabilité de votre application est primordiale ce sera dans ce cas peut être vers JAVA que vous vous orienteriez, quoique le couple Qt/C++ soit aussi une solution intéressante.

Autodesk Maya,  developpé en Qt/C++


Si votre application nécessite une connexion à un serveur, pour afficher du contenu en ligne, les données d'un compte bancaire, ou tout autres action qui nécessite que l'information soit centralisé sur des serveurs. Dans ce cas 2 choix s'offrent à vous : Le Client Riche et le Client Léger.

Le Client Riche

Le Client Riche est en fait un client lourd, auquel on à greffé des capacités à se connecter, à chercher de l'information sur un réseau. Cela permet d'une part de rendre l'affichage des informations dynamique, mais aussi, dans certains cas d'alléger le traitement fait sur le poste client. En effet le serveur peut exécuter des traitements à la place du poste client. Dans le traitement des données par exemple, on aura tendance à déporter des calculs sur le serveur et à n'envoyer que le résultat au poste client. Cette infrastructure à l'avantage de repousser l'obsolescence du matériel des postes client, vu qu'on leur demande moins de puissance, tout en conservant un look & feel en accord avec le système d'exploitation de la machine. De plus cela permet toujours de demander au poste client d'exécuter des calculs lourds, comme des rendus 3D, ou des animations. Le client Riche s'impose donc lorsque l'on a un besoin de connectivité et de puissance et que l'on souhaite stocker des données sur le poste client.

Reeder pour mac


Le Client Léger

Enfin le Client Léger quand à lui dispose de l'extreme avantage ( pour le concepteur et le mainteneur ) de ne rien stocker sur le poste client. Concrètement quels avantages cela apporte t'il ? Simplement dans la question des mises à jours de l'application cela est un énorme avantage. En effet la mise a jour se fait de manière totalement transparente, vu que l'interface est téléchargée depuis le serveur à chaque lancement. Le client léger s'impose donc lorsque l'on a la nécessité de mettre à jours fréquemment l'application, tant dans son fond, que dans sa forme. Le désavantage de cette solution est que pour l'instant les composants de l'application ne permettent pas d'obtenir les mêmes rendus que les composants natifs du poste client. Du moins on est limité aux capacité du web ou des frameworks RIA. Le plus souvent, l'application est isolée dans une fenêtre de navigateur, mais certaines solution, comme Adobe Air permettent d'obtenir une application indépendante du navigateur et plus ou moins "maquillée" comme une application native.

De nombreux frameworks existent pour faire du client léger, je ne vous citerai que GWT (Google Web Toolkit, permet de créer des interfaces renduent en HTML en codant en JAVA) et Adobe Flex ( Détournement de la technologie Flash pour faire des interfaces en ligne avec une intégration de la vidéo et des animations que le HTML ne permet pas ). Vu que le client léger n'a pas accès aux données du poste client par mesure de sécurité ( ce que l'on appelle "sandbox" ), il n'est pas possible de stocker directement ou de lire des informations en local. Tous est déporté sur le serveur. Il existe grâce à Air un moyen de porter des applications créées avec les technologies du web sur le poste client. On peut ainsi repousser ces limites du clients léger en stockant en local, mais au final on perd l'intérêt du client léger pour revenir vers du client riche. Enfin il vous reste l'option de passer par la méthode traditionnelle, à savoir le HTML + CSS + Javascript, qui permet elle aussi de créer des applications (certes de moindre importance, car le type de code ne permet pas une bonne maintenance sur les gros projets),  à la manière d'un site web.

Application faite avec Ext-GWT

Pour faire le point voici une infographie très parlante de Camille Roux permettant de faire le point sur les différentes technologies en matière d'interfaces selon l'axe que nous avons abordé.



J'espère qu'au final ce billet aura éclairé vos lanternes. Je pense dans un futur plus ou moins certain me pencher sur la création d'un article ou je détaillerai les différentes technologies pour chacune de ces infrastructures. N'hésitez pas à laisser vos avis si vous pensez que je me suis lamentablement gouré sur un point ^^ Bonne continuation.

samedi 25 décembre 2010

Chrome et Firefox sur mac, perfectibles performances.

Bien que je sois un inconditionnel utilisateur de Chrome sur mac, je m'étonne de l'écarts de performance entre ce navigateur et Safari le navigateur d'origine de Mac OSX. En effet en faisant des test sur une interface web utilisant Flash et javascript je me suis rendu compte que Chrome accusait d'un certain retard sur Safari en terme de performances dans la gestion de Flash et du Javascript. En testant d'autre navigateurs j'ai constaté que c'était également le cas de FireFox. Pour certain rendu Chrome et Firefox utilisaient près de 90% du CPU au lieu de 30% pour Safari. Opera, quand à lui se rapproche de Safari avec une consommation légèrement supérieure.

Pour en avoir le coeur net, vous pouvez faire un test. Jouez une animation Flash assez gourmande devant une image bitmap d'une assez grand taille. La propriété wmode du swf doit être transparente.

Résultat Chrome consomme énormément de CPU, si vous redimentionnez la page étrangement la consommation de cpu va baisser mais sans atteindre la quiétude d'un Safari. Mon hypothèse est que Chrome recalcule la superficie totale de l'image a chaque frame de l'élément Flash, au lieu de ne recalculer que la zone que celui ci occupe. Lorsque l'on redimentionne la fenêtre, Chrome redimentionne l'image de fond sans appliquer de traitement antialiasing, ce qui fait que l'image n'est pas totalement nette. Rendre une image sans traitement antialiasing est moins consommateur de CPU, la différence est flagrante quand l'image est générée 24 fois par seconde. Voir ci-dessous les performances de chaque navigateur.

Chrome rendu de base 
Chrome après rendimentionnement


Pour Firefox il se produit d'étranges phénomènes, selon la dimension de la fenêtre la consommation du cpu passe du simple au double. En réduisant la fenêtre, passé un certain seuil la consommation s'emballe. Et la, je n'ai aucune explication.

Firefox qui en chie (mystérieusement)
Firefox qui gère


Opera
Safari

Safari et Opera restent inébranlable dans leur traitements, le processeur ne s'emballe pas. Alors s'agit il alors d'une optimisation que les gars de chez Google et Mozilla auraient zapé dans la course? Ou bien serait ce parce que Apple conserve une certaine avance sur l'utilisation de ses propres outils ? N'empeche que Opera a bien réussi a talonner Safari. En définitive je conseille de rester sur Safari, le rendu des animations, la gestion du CSS3, du Flash… Même si pour moi Chrome est une merveille en terme d'ergonomie, sur un point purement technique Safari reste un maître.

mercredi 22 décembre 2010

Blocs aux coins arrondis de taille variable sans CSS3

Bon parce que ce blog est aussi mon fourre tout, voici un billet qui n'a rien a voir avec mes précédents articles. Voici donc un petit tutoriel HTML/CSS, pour tous ceux qui ont le soucis de rendre leur site web soigné ET performant.
Et oui je suis un grand fan des possibilités qu'apporte le CSS3. En 2 lignes il est possible d'arrondir un bloc et de lui mettre une ombre portée ce qui évite un travail fastidieux dans Photoshop ou Gimp. Malheureusement outre le fait que le CSS3 n'est pas encore pleinement géré dans tous les navigateurs, qu'il faille rajouter des "-webkit" et "-moz" pour que chaque navigateur compatible l'interprète… Et bien le CSS3 consomme encore pas mal de ressources. Si vous comptez réaliser un bloc de taille variable et qui en prime soit animé, il y a des chances que votre animation manque de fluidité, surtout sur les tablettes et smartphones. Ainsi donc voici un tuto basique qui vous montrera une possibilité parmi tant d'autre de créer un bloc aux bords arrondis, de taille variable, et qui s'anime de manière parfaitement fluide.
Tout d'abords réalisez votre bloc arrondis dans votre logiciel de dessin préféré.


L'art dans la réalisation d'un bloc de taille variable réside dans les propriétés repeat-x et repeat-y du CSS. il y a des zones dans les bordures qui seront dupliquées selon ces 2 axes. Pour ma part j'ai créé un bloc avec un degradé jusqu'à un certain niveau, je ne pouvait donc pas placer ma zone de duplication ou bon me semblait.

Disposez donc les règles qui vont délimiter les différentes portions du bloc. Si vous souhaitez que la taille du bloc ne varie que sur un axe alors découpez votre bloc en 3 morceaux et non en 9 comme je l'ai fait. La partie centrale du bloc, celle qui sera dupliquée doit toujours être la plus "mince" possible, du coup 1 pixel. Une fois vos règles positionnées le découpage peu commencer, faites 1 fichier pour chaque morceau. Attention certain morceau doivent avoir la même hauteur ou largeur sous peine d'être décalés.


Une fois le découpage effectué, il faut passer aux chose sérieuses et mettre le main dans le code.

Codez moi donc un joli tableau, de 3 ou 9 case selon le nombre d'axe que vous souhaitez faire varier la taille. Dans chaque case, mettez la taille de votre image, ainsi que l'image en question en background. A la fin n'oubliez pas de mettre les style de margin et de padding à 0, sous peine d'avoir des écarts entre les cases.


Voila, normalement vous y êtes et pour faire varier la taille de ce bloc, il ne reste plus qu'a jouer sur la taille de la case centrale de votre tableau.
- C'est bien beau tous ça mais ou je met mon contenu dans ce bloc?
Ahah, en effet, l'astuce réside dans la création d'un bloc "div" en dessous de votre joli tableau, et ensuite de lui affecter un margin-top négatif pour le remonter et le superposer devant votre tableau. Mettez votre contenu dans ce bloc et n'oubliez pas de rajouter un style "position:relative;" pour que IE ne fasse pas sa crise.



Voilà, vous avez normalement un joli bloc de taille variable, personelement j'anime ensuite ce bloc via JQuery, et ça marche nikel. J'espère avoir été assez clair dans ce petit tuto qui est aussi mon premier :) Je vous met un zip avec les sources via ce lien. N'hésitez pas à posez vos question si vous en avez. Allez bon courage.