Laurent J a écrit 2933 commentaires

Ce n'est pas parce que c'est fait en javascript, qu'il faut imputer les problèmes de perfs à l'implémentation javascript.

Déjà, Javascript, ce n'est qu'un langage. Prend la spec d'Ecmascript, et tu n'y trouveras nulle part référence à DOM, canvas etc. En d'autres terme, un moteur javascript, ça n'implémente que l'interprétation de la syntaxe JS, quelques objets de base (Math, Array, String, Number etc...), et tout le reste que l'on utilise très souvent en JS (comme l'objet window, le DOM etc), ce ne sont que des API implémentés dans des libs à coté (rien à voir avec le JS donc), et importé dans le langage JS

Bref, dans ce genre d'application très graphique, le javascript n'a que peu de part de responsabilité dans les problèmes de perfs. Surtout que TraceMonkey (moteur de Firefox), compile en code machine pur tout ce qui est calcul mathématique js avant exécution (en particulier dans les boucles).

Si on veut un responsable sur les perfs, et dans une appli web comme celle là, il faut se tourner donc vers le DOM, et plus particulièrement ici vers la balise canvas.

Chez Mozilla, on sait que la couche de binding DOM <-> javascript n'est pas des plus performantes, et dans le trunk, (et la branche Fx 3.6 je crois), il y a eu des améliorations assez significatives en ce sens.

Ensuite, canvas. Dans Firefox, canvas, ce n'est qu'une API haut niveau au dessus de la bibliothèque Cairo (http://cairographics.org/ ). Autant dire que les mesure de perfs purement graphiques sont à imputer à Cairo. Reste à savoir dans quel mesure Cairo contribue à la dégradation des perfs en globalité.


Pour conclure, ne pas confondre javascript et les dizaines de composants que contient un navigateur.

>C'est un peu comme l'histoire de l'A6 qui a déja été rentabilisée à plus de 100 fois sa valeur, mais qui pourtant ne baisse pas ses prix.

Tu as raison. Une autoroute, ça ne s'entretient pas, et depuis la construction, ils n'ont jamais fait de réfection de la chaussée, aménagé de nouvelles aires d'autoroute ou refaites celles existantes. Ils n'ont pas non plus de personnel (et le materiel qui va avec) pour nettoyer les bords de l'autoroute, surveiller et être là au moindre accident etc....

ne pas confondre thread et processus. Bien sûr que Firefox utilise des threads depuis des années : pour les requêtes réseaux, pour les traitements n'ayant pas une interaction directe avec l'affichage etc.

Utiliser des threads pour chaque onglet, ça n'apporterais rien : les threads sont dans le même processus d'exécution, donc si ça plante dans l'un, tout plante.

Par contre oui, un *processus* par onglet, ça apporte une sécurité dans l'execution. Et c'est effectivement ce qui est fait dans Chrome et bientôt dans Firefox (c'est en cours de dev). Mais bon, ça occupe aussi beaucoup plus de mémoire (Chrome occupe plus de mémoire que le FF actuel dans pas mal de cas), et ça complexifie les communications entre onglet, avec le reste du navigateur (stockage de l'historique, du bookmark, synchro des prefs etc etc...).

seul problème de ce type de FS : quand tu veux copier ton fichier vers une autre machine (linux, windows etc), tu perds toutes les métas datas.. Donc dans certains cas, des informations..

>Devra-t-on payer en supplément pour pouvoir utiliser le code-barre?

bah oui. Puisque si j'ai bien compris, la video/ le document est téléchargé sur ton téléphone -> tu bouffes ton forfait (même si c'est du "illimité", tu bouffes ton quota de BP -> tu arriveras plus vite aux limites de ton "illimité").

À moins que ces videos/documents téléchargés à partir d'un site spécifique ne soit pas pris en compte dans ton quota...

Enfin bon, nouveau service, donc forcément, tu le payes quelques part.

C'est déjà très correcte, ne serait-ce que pour développer. Pas besoin de s'acheter une licence super chère pour développer une appli sur base oracle pour un client.

Le fait que ce soit du raster ou des fichiers complexes n'est en aucun cas une raison de ne pas faire des sauvegardes automatiques, même à intervalle court.

Il suffirait juste d'enregistrer la pile d'undo (dans un fichier à part, "special anti crash"), et donc juste le type des actions avec leurs paramètres. À chaque fois, ça ne serait que quelques dizaines d'octets à sauvegarder dans ce fichier anti-crash (et bien sûr, on n'enregistre que les actions qui n'avaient pas été sauvée)..

Et ainsi à la restauration -> rejouer la pile d'undo sauvegardée.

Et si on veut éviter de se retrouver en sauvegarde avec une pile d'undo énorme, on pourrait sauvegarder le vrai xcf toutes les 10 minutes (ou selon le user), et ça, ça pourrait se faire aussi dans un thread, pour éviter de trop géner le user.

Bref, il y a des solutions qui pourraient être implémentées.

sur le blog d'apache

https://blogs.apache.org/infra/entry/apache_org_downtime_ini(...)

j'ai juste repondu avec le même "tact" que ta question :-p

Une bonne grosse boutade quoi (en plus pas originale, je l'avoue...).


>Donc si je te suis bien, je vais patcher chaque outil que j'utilise qui doit répondre a des besoins que je ne suis pas le seul a avoir

chaque outils, non, bien évidement (ai-je dis ça ?). Mais si une fonctionnalité manquante est est très importante pour toi, pourquoi pas ? Ou même encore, pourquoi pas payer un dev pour le faire ? (ta boite ou toi, si il y a les sous, mais pas le temps ou pas les compétences).

C'est comme ça que fonctionne la grande majorité des projets Open Source.

>Mac OS X qui propose déjà un profiler de code performant

bah à priori, ce profiler n'a pas l'air de convenir à la majorité des dev Mozilla qui bossent sous Mac. Donc ils ont payé un gars pour le faire.

Tu n'as plus qu'à espérer que des dev Mozilla passent sous un BSD en masse pour voir le portage arriver :-)

Mais, euh... je te conseille de trouver une autre solution que d'attendre après Mozilla ;-)

quand tu auras filé ton patch.

"une bonne partie des animations SVG/SMIL"

Tout n'est pas totalement fini c'est tout. Dans ce genre de truc, vaut mieux avoir un truc fini qu'un truc à moitié fini... En fait le coeur est là, mais y a pas tout exposé encore si j'ai bien compris.

Le fait d'utiliser un processus par tab peut jouer au niveau rapidité. Mais il n'y a pas que ça. L'interface de Firefox, c'est du XML + JS. ça demande donc un peu plus de temps à réagir que du pur natif.

Pour le chargement du navigateur, il y a des trucs un peu lourd dans Firefox, et ils sont en train d'améliorer tout les points noirs.

bah si y a beaucoup d'IPC à faire : mise à jour de l'historique, paramètrage du navigateur, communication avec le download manager, le security manager etc etc. Un tout petit exemple : dés que tu ouvre une url, faut que le navigateur aille informer tout les autres tabs, pour que les styles des liens en :visited soient mis à jour. Et des trucs comme ça, il y en a beaucoup.

Bref Il y a beaucoup de communication inter processus. Pour te faire une idée, voir le dev qu'il y a actuellement dans Firefox pour faire un processus par tab: https://wiki.mozilla.org/Content_Processes

Ils réutilisent d'ailleurs la couche IPC de chromium ;-)

Les points manquants de Firefox sur le test acid3 concernent majoritairement le support des animations SVG/SMIL. C'est pas la fin du monde :)

La prochaine version de Firefox fera mieux évidement, car une bonne partie des animations SVG/SMIL sont implémentées, mais pas activé par défaut pour le moment dans le futur Firefox 3.6 qui sortira dans 3 mois. (oui oui, dans 3 mois, en novembre 2009).

La nightly de FF3.6 avec la préférence svg.smil.enable à true : 97/100. sans la pref: 95/100.

un fabricant qui a une capitalisation boursière plus grosse que Google, c'est pas un grand fabricant ?

http://www.generation-nt.com/capitalisation-boursiere-apple-(...)


J'aimerai bien alors diriger une petite boite comme Apple...

> Il s'applique à tous les fichiers dont le format comprend des marqueurs (métacodes), donc XML mais aussi HTML et bien d'autres formats.


ben non justement, si j'ai bien compris le procédé. Le brevet explique une technique où le contenu est séparé de la structure. Tu le dis toi même : content et map sont séparés. Or en XML/HTML, le contenu est à l'intérieur même de ce qui décrit la structure (les balises formant la structure).

Et cela semble être confirmé par ce que je viens de lire un peu partout : ce n'est pas l'utilisation du format XML qui est remis en cause, mais la manière dont sont stockées certaines données dans le format XML de Microsoft (avec j'imagine, un truc du genre des données brutes dans une balise, et une map dans une autre).

Ce brevet n'en reste pas moins totalement ridicule.

note : je bosse une boite qui fait de la techno sur le zoom de document et d'images.

les niveaux de zooms sont prédéfinies ok, les tuiles sont bien entendu précalculés. Mais quand tu veux faire du zoom linéaire et non incrémentale, (donc, il faut étirer/rapetisser les tuiles au finale, quand le zoom est entre deux niveau de zoom), comme c'est le cas pour notre outils, bah tu as forcément à un moment ou à un autre des tuiles disjointes à l'affichage, à cause des arrondis. Il faut donc toujours qu'une tuile puisse déborder sur une autre, ne serait-ce que d'un pixel ou deux.

Quand tu as un affichage de zoom à des niveaux prédéfinis (on ne peux pas zoomer entre deux niveaux de zoom), oui, tu n'a pas besoin que les tuiles se chevauchent, puisque tu affiches alors les tuiles telles quel (même si tu fais une jolie transition quand tu passes d'un niveau de zoom à un autre, en étirant/rapetissant les tuiles temporairement. si il n'y a pas de jointure parfaite durant la transition, c'est pas grave, ça ne se verra pas.

Ben si, c'est du flash. les boutons sont en HTML, mais le player en lui même est bien en flash.. (ils pourraient utiliser la balise quand même...)

Et sinon, franchement, je ne suis pas fier que ce soit français. Vu la gueule du HTML (via firebug), à la place des développeurs, je me cacherai. Parce que par exemple, imbriquer neuf DIV pour enfin afficher le contenu principal de la page, avec en plus du style inline et des classes (les mêmes en plus) dans tout les sens, ça craint du boudin... Je plains ceux qui doivent le maintenir (quoique, si c'est ceux qui l'ont développé...)

Bref, leurs pages pourraient être bien plus light et compréhensibles... Deezer, au moins, le code est un peu mieux organisé.


(désolé, c'est mon coté critique dev web qui ressort)

LOL.


(ouai, je sais, avec ce LOL, je me grille encore plus, mais que voulez vous...)

non, pas comme des pavés. Parce que des pavés, ça se chevauche pas. Des tuiles, ça se chevauche. Et justement, dans le domaine du zoom, en général, on fait légèrement chevauché les images, pour compenser les arrondis dans les calculs de zoom/taille. bon, peut être pas sur google map ou mappy, vu qu'ils ont des niveaux de zoom déterminés (quoique, j'ai pas regardé le code en détails). Mais quand on a un système de zoom sans "échelons", on est obligé de les faire chevaucher sinon on peut avoir des images disjointes à certains niveau de zoom, et ça c'est moche :-).

Bref, des tuiles quoi..

Il n'y a plus de flash.

Mais il n'y a absolument pas une once de balise SVG. Ou alors va falloir me dire où tu en as vu.

En explorant l'arbre DOM avec Firebug, je n'ai vu que des images. La carte est découpée en plusieurs images (qu'on appelle des tuiles dans le jargon du domaine du zoom). Bref, une technique similaire à Google, open street map et cie. Que du JS (avec jQuery), et des balises html img. Pas de SVG.

>Et vous qu'en pensez-vous?

rien.

Sous linux chez moi, ça fonctionne très bien.... (que ce soit des binaires vanilla ou compilé maison)

bah, avec Firefox 3.5 et des videos Theora, j'arrive à aller directement où je veux sans tout télécharger...

Tu as essayé avant de poser la question ?

de toute façon, il n'y a pas besoin de patcher soit même chez Mozilla. à partir du moment où le patch est inclus dans le dépôt mercurial, tu as des builds à ta disposition qui comportent la correction (que ce soit des builds des branches stables ou du trunk).