Discussion :

[Zenol]

Personnellement, en écrivant ce message j'ai 104 ongles d'ouvert(un peu de flash, beaucoup de mans, des sites bien conçues et d'autres moins), et je dois dire que dans ce genre de conditions, firefox "a du mal", mais ca passe.

Par contre, pour le démarrage, 4 secondes, c'est plutôt optimiste.
(Pour moi, c'est déjà trops)

Depuis les dernières version firefox est plus stable. (La version précédant était propice au crash sur des sites flash comme deezer)

Je me demande ce que donnerais chrome dans une même situation? Serais-t il toujours aussi fluide. (Je ne me sent pas le courage de tester)

Il est claire que la plupart d'entre nous appréciais une amélioration des performances, et un lancement plus rapide(quitte à ce que le démarrage se poursuivent de manière asynchrone).

(Par exemple, pour la lecture de flux-RSS, il n'est pas "urgent" qu'elle soit opérationnel immédiatement après le lancement de firefox. On peux se permette d'attendre 3,2secondes de plus si firefox se lance avec 3 secondes de moins.)

En tout cas, si chrome est rapide, il ne permet pas tout ce que permet firefox. (Donc, pour moi la question de changer de navigateur ne se pose pas, chrome ne répondant pas à mes besoins)

[LooserBoy]

... et en faisant en C# mon propre navigateur (un peu a l'arrache hein ^^) avec un controlleur WebBrowser (donc basé sur IE) :

0ème) avec 65Mo

Ah oui quand même... et le comportement est strictement le même ?

[Nesbit]

Chrome décompose ses processus en fonction des onglets (autant de processus que d'onglets) donc la mémoire est divisée par processus (ce qui fait surement sa rapidité) mais il demande plus de ressources que Firefox.

Exactement !!!
Je ne sais pas pourquoi "tout le monde" dit que FF consomme trop de mémoire. J'ai déjà fait plusieurs tests sur ça (1 onglet, plusieurs onglets, avec flash, sans flash, etc... ) et j'ai trouvé que pour la plupart des cas, la consommation de mémoire de Chrome >> FF (attention: pour Chrome, il me fallait utiliser une calculatrice pour faire la somme des processus).

(P/s: Pour Opera 10.5 final c'est encore pire)

[jblecanard]

Comme le disait un autre internaute, il y a quand même une confusion entre la réactivité et la consommation mémoire.

Si Chrome s'octroie en une seule instruction une grosse plage de mémoire, il sera très réactif à l'intérieur de celle-ci, quitte à ne pas tout utiliser. Tandis que si FF grignote la mémoire dont il a besoin au fur et à mesure, il perd en réactivité : l'allocation de mémoire est très consommateur de ressources.

Pourtant, on a tendance à penser (souvent à juste titre) qu'une appli qui met plus de temps à démarrer est plus lourde en mémoire. Il semble que ce soit faux dans le cas présent.

[cs_ntd]

et le comportement est strictement le même ?

Presque. En le testant "profondément", il y a certains problèmes (certaines zones JavaScript s'affichent pas ou mal), par exemple (mais rien de trop trop dérangeant).
Je n'ai aussi pas trouvé (pas trop cherché ^^) pour l'instant la manière d'ouvrir les pages qui veulent s'afficher dans une nouvelle fenêtre, dans une nouvelle instance du navigateur (à moins de le mettre navigateur par défaut).

Je n'ai pas aussi implémenté la gestion des favoris et une gestion correcte de l'historique (mais c'est pas ça qui prendra 10Mo). Sinon, ya toutes les fonctionnalitées "basiques" (précédent, suivant, home, stop, refresh...), en gros tout ce que j'utilise dans un navigateur (pas d'onglets par contre).

Mais à par ça, le comportement est quasiement le même (il y a les mêmes paramètres que dans IE), en tout cas bien suffisant pour une navigation ordinaire.

En plus l'ouverture est instantanée, et la navigation vraiment plus rapide que dans les 3 autres.

A la base, on m'avait demandé de le faire car IE8 et FF3.5 bouffais toute la RAM disponible sur un (assez, mais trop) vieux PC, et le faisait planter... (ou freezer régulièrement). Depuis, plus de soucis

[Rapha222]

Mise à jour du 27/01/10
NB : Les commentaires sur cette mise à jour commencent ici dans le topic



"Il y autant de différences entre Webkit et Gecko qu'entre une pomme et une banane"
Exclusif : La Fondation Mozilla répond aux questions des membre de Développez (partie 2)


Suite de l'entretien que Tristant Nitot, Président Fondateur de Mozilla Europe, et Paul Rouget, techno-évangéliste pour la Fondation, ont accordé à Développez pour répondre à vos questions.

Si vous avez loupé le début, la première partie est ici.



Certains veulent unifier les lois de l'univers, à DVP on est plus modeste : beaucoup souhaiteraient juste unifier les moteurs de rendu Webkit et Gecko. Est-ce imaginable ? Et quelles sont les barrières actuelles qui l'empêchent ?

TN : (sourire) Ce n'est pas vraiment à l'ordre du jour.

PR : Il faut bien voir que Webkit et Gecko n'ont rien à voir. Je connais très bien les deux et ils ne fonctionnent pas du tout de la même manière. Gecko implémente ses propres bibliothèques (sécu, abstraction system, réseau, …) alors que WebKit délègue tout ça.

TN : les deux moteurs sont architecturés de manières complètement différentes

PR : C'est un autre modèle. Nous on a décidé de tout intégrer dans Gecko, de cette manière on ne dépend pas des librairies qui varient forcément d'un utilisateur et d'un OS à l'autre. Comme Gecko est libre chaque développeur peut reprendre les modules qu'il veut et les modifier si ça lui chante. Est-ce que tu sais par exemple que NSS, le module de sécurité de Gecko, est utilisé par Pidgin ? Ou que XPCom (le gestionnaire d'objet) été repris par Sun dans VirtualBox ?
Ce n'est qu'un exemple mais tout ça pour dire qu'une fusion entre les deux moteurs n'est techniquement pas possible parce qu'ils ne relèvent pas de la même conception. Il y autant de différences entre Webkit et Gecko qu'entre une pomme et une banane...


A venir :

Dans la suite de l'interview nous quittons les moteurs de rendu pour les extensions. Vous aurez par exemple la réponse de la Fondation à Google, qui affirme qu'il est plus beaucoup plus simple de développer des add-ons pour Chrome que pour Firefox.


Et vous ?

Etes-vous déçu qu'il n'y ait pas de fusion prévue entre Gecko et WebKit ?
Que pensez-vous des arguments avancés pour expliquer qu'il n'y aura pas d'outil commun ?

http://www.pcinpact.com/actu/news_multi/55775.htm
Finalement, elle était pas si bête mon idée alors ^^

[Uther]

Il s'agit juste de reprendre une partie du moteur Nitro. Utiliser du code en provenance externe à toujours été fait(beaucoup de code de firefox, viens d'IBM et Adobe entre autre) et continuera d'être fait. Mais changer l'intégralité du moteur de rendu est autre chose.

Toute l'interface de firefox reposant entièrement sur le moteur Gecko, passer à webkit reviendrait à refaire un autre navigateur.

C'est un peu comme si tu disait, le foot c'est bien, mais il faudrait comme au rugby que l'on puisse jouer à la main, sans faire de passes en avant et aplatir le ballon derrière la ligne. C'est plus du foot et le rugby existe déjà pour ça.
Par contre ça serait pas idiot que le foot s'inspire du rugby pour l'arbitrage vidéo.