Discussion :

[ferber]

J'ai hate de voir également leur implémentation de Flash. J'en ai ras le bol de voir flash planter sans cesse ou de bouffer pleins de ressources.

La c'est sur tu ne verra plus flash planter, mais Firefox lui peut être.
Mais le plus souvent tu n'aura qu'un rectangle vide. Et une très grande conso mémoire.

Pour l'instant shumway est inexploitable.
Je ne dit pas sa pour être vexant, je dit ça car je l'ai testé.
Il y'as une machine virtuel qui représente surement un travail énorme.
Mais derrière presque aucune des classes de base de flash n'est implémenté.
Du coup il suffit d'utiliser une seule de ces classes de base pour que tout s'écroule. Alors forcement ça ne vas pas loing, surtout que pour trouver les classe de base manquante il faut passer par fire bug pour suivre tout le déroulement de l'animation car aucune sortie en débug n'indique que shumway ne connait pas tel et tel class.
Alors franchement c'est plus une blague ce lecteur flash.
Mais une blague qui a du coûter un max d'heure de travail au développeur du projet. sans parler qu'as l'heure actuel shumway est a peux près 30 fois plus lent que le lecteur flash. ( comme je le montrait sur la discutions sur shumway ) et ce juste sur une simple boucle while.
Donc désolé de casser vos illusions mais le lecteur flash en javascript c'est une bonne grosse mauvaise idée de développeur qui pense que le html5 peut rivaliser avec du code natif.

[LSMetag]

La c'est sur tu ne verra plus flash planter, mais Firefox lui peut être.
Mais le plus souvent tu n'aura qu'un rectangle vide. Et une très grande conso mémoire.

Pour l'instant shumway est inexploitable.
Je ne dit pas sa pour être vexant, je dit ça car je l'ai testé.
Il y'as une machine virtuel qui représente surement un travail énorme.
Mais derrière presque aucune des classes de base de flash n'est implémenté.
Du coup il suffit d'utiliser une seule de ces classes de base pour que tout s'écroule. Alors forcement ça ne vas pas loing, surtout que pour trouver les classe de base manquante il faut passer par fire bug pour suivre tout le déroulement de l'animation car aucune sortie en débug n'indique que shumway ne connait pas tel et tel class.
Alors franchement c'est plus une blague ce lecteur flash.
Mais une blague qui a du coûter un max d'heure de travail au développeur du projet. sans parler qu'as l'heure actuel shumway est a peux près 30 fois plus lent que le lecteur flash. ( comme je le montrait sur la discutions sur shumway ) et ce juste sur une simple boucle while.
Donc désolé de casser vos illusions mais le lecteur flash en javascript c'est une bonne grosse mauvaise idée de développeur qui pense que le html5 peut rivaliser avec du code natif.

En même temps, je n'attends pas une version utilisable de Shumway avant au moins un an. Là on en est qu'au stade expérimental. Je sais également que sans accélération matérielle, ce sera moins performant. Je recherche surtout la stabilité ainsi qu'une amélioration de la sécurité.

Sinon, pour Firefox, il peut m'arriver d'atteindre les 1 go de pris, mais au bout de 3 jours de surf avec 10 extensions. Donc je laisse le bénéfice du doute.

Comme je le disais ce qui est intéressant chez Firefox, c'est qu'il n'a aucune vraie tare.

[ferber]

En même temps, je n'attends pas une version utilisable de Shumway avant au moins un an. Là on en est qu'au stade expérimental. Je sais également que sans accélération matérielle, ce sera moins performant. Je recherche surtout la stabilité ainsi qu'une amélioration de la sécurité.

Je pense pas que l'accélération matériel, puisse optimiser la vitesse d'exécution des javascript.
Personnellement je pense que ce projet a peu de chance de sortir du stade expérimental, a moins de faire un titanesque bon en avant.
Ce qui me semble peut probable, au mieux il arriverons a faire un lib permettant d'afficher des petite bannières de pub en html5.
Mais un moteur d'exécution AS3 correcte, la je pense pas, a moins que les moteur javascript devienne plus de 30 fois plus rapide que le flash player, dans ce cas de figure sa pourrait passer.

[yoann.boukredine]

Bench Html 5 avec html5test
http://html5test.com/

FF-17.0.1 : score 371
Elements 25/35
Grouping content elements : Partial
XMLHttpRequest Level 2 : Partial
Communication : 29/35

FF-18 : score 378
Elements 26/35
Grouping content elements : Yes
XMLHttpRequest Level 2 : Yes
Communication : 35

-> du mieux donc pour le support HTML5...

Sunspider :
http://www.webkit.org/perf/sunspider/sunspider.html

FF-17.0.1 :
Total : 323.0ms +/- 1.2%

FF-18 :
Total: 341.8ms +/- 2.3%

Bizarre, pas de gain...

Chrome-23 est toujours meilleure de FF-18 via le bench V8 (higher better)
Chrome-23 : Score: 7716
FF-18 : Score: 5750

A vos tests via les outils avant de faire votre mise à jour de navigateur
http://en.wikipedia.org/wiki/Browser_speed_test

Yobo

[Tryph]

Sunspider :
http://www.webkit.org/perf/sunspider/sunspider.html
[...]
Chrome-23 est toujours meilleure de FF-18 via le bench V8 (higher better)
Chrome-23 : Score: 7716
FF-18 : Score: 5750

je fais pas de tests moi même alors je vais pas contredire mais je vais quand même émettre une réserve:
utiliser le test de webkit.org pour comparer un navigateur basé sur webkit à un autre, c'est pas ce qu'on peut faire de plus objectif a mon avis.


Edit:
je viens de retrouver un site qui permet de tester différentes version d'un code JS pour faire des optimisations, et dans ce site je viens de retrouver un test qui permet de mettre en valeur un truc:
http://jsperf.com/string-concatenation123/4
faut faire tourner le test une fois pour avoir accès aux graphiques (sous le tableau), mais ce site met bien évidence que 2 codes qui font la même chose peuvent avoir des performances très différentes suivant la méthode utilisée.
encore mieux: une façon de faire peut être rapide sur un navigateur et lente sur un autre, et inversement pour une autre façon de faire.
ainsi, je me dis que ça doit pas être bien difficile d'écrire des tests qui mettent en évidence la supériorité d'un navigateur particulier.

(bon après, il semble bien que chrome soit même souvent plus rapide que firefox pour l'exécution du javascript)

[LinxBe]

Gros problème sous Microsoft Windows (XP):

impossible de relancer Firefox 18 après l'avoir arrêté !!!
("Firefox est déjà en cours d'exécution mais ne répond pas. Pour ouvrir
une nouvelle fenêtre, vous devez d'abord arrêter le processus Firefox existant ou redémarrer votre système.")

--> obligé chaque fois de tuer le processus par le 'Gestionnaire des tâches' avant de redémarrer Firefox !
Sinon, à la fermeture de session, message:
"Le programme D3D9Window ne répond pas. Terminer maintenant ?"

PENIBLE !!!!

Comment peut-on revenir à la version précédente, qui fonctionnait sans problème ???

[Flaburgan]

Bonjour LinxBE, et merci d'utiliser Firefox

Je n'arrive pas à reproduire ton problème. Peut-être celui-ci vient-il d'un plugin / une extenstion. Peux-tu réessayer après les avoir désactivé ?

Merci à toi !

[LinxBe]

Bonjour Flaburgan,

Le problème a été résolu de puis longtemps (4 ans).
Je m'aperçois que je ne t'ai jamais remercié de ta réponse.
Voilà qui est fait ! Mieux vaut tard que jamais

Linx

Bonjour LinxBE, et merci d'utiliser Firefox

Je n'arrive pas à reproduire ton problème. Peut-être celui-ci vient-il d'un plugin / une extenstion. Peux-tu réessayer après les avoir désactivé ?

Merci à toi !