Firefox 3 a trouvé la pédale d'accélérateur

Florian Innocente |
Vladimir Vukićević, de l'équipe de développement de Firefox, affirme sur son blog que la bêta 4 de Firefox 3 (attendue ces prochains jours) devrait se montrer nettement plus réactive que les précédentes bêta. Mais il conviendra d'utiliser au minimum la version 10.4.4 de Mac OS X pour en tirer profit (la 10.3 n'est de toutes façons plus supportée). C'est le résultat de quelques réglages réalisés après plusieurs analyses du comportement du logiciel.

Mais la principale découverte de Vukićević fut que Safari utilisait pour sa part des interfaces de programmation spécifiques pour arriver à booster ses performances. Et ces API "secrètes", il en a dénombré environ 100, ne sont accessibles qu'aux développeurs d'Apple. Il a coeur à souligner qu'il n'y voit pas pour autant une volonté d'Apple se s'arroger quelques privilèges et avantages. Après tout Firefox 3 devrait montrer de belles performances, mais il aimerait que certaines informations sortent du cercle restreint des développeurs de Cupertino.

David Hyatt, ancien de Mozilla et patron du développement de Safari a répondu à son billet, expliquant que la méthode sur laquelle s'appuyait Safari était loin d'être parfaite, d'où son caractère non publique. Il souligne aussi que certaines choses restent d'ordre privé, car elles s'appuient sur des composants internes qui doivent le rester ou qui ne sont pas prêts à être dévoilés. Il ajoute que son équipe signale à celle de Mac OS X, lorsque c'est nécessaire, que des rouages du système mériteraient d'être documentés pour un usage par des développeurs tiers.

avatar Yamtaijika | 
Vuki quoi ?....
avatar cyberdog | 
J'utilise Minefiled 3.0B4pre_fr et il est déjà beaucoup plus rapide que la 3.0ßéta3 . cyberdog
avatar Ziflame | 
@Yamtaijika Vukićević = ± Vukitchevitch
avatar Ziflame | 
Et ce Vladimir Vukićević devrait peut-être commencer par utiliser du Cocoa pour Firefox, au lieu d'utiliser du papier, carton, scotch et pritt pour l'interface de son browser...
avatar Anonyme (non vérifié) | 
Franchement, la tronche des boutons ronds... c'est du foutage de gueule firefox... :D
avatar lifenight | 
Ziflame Si tu veux un firefox en cocoa, tu peux oublier les extensions. Firefox est en xul et c'est ce qui fait qu'il est portable facilement sur un autre os. Firefox c'est pas du bricolage puisqu'il utilise les api de mac os x. La Minefield 3.0B4pre_fr est quasi aussi rapide que Safari
avatar Ziflame | 
@lifenight La portabilité ce n'est pas tout dans la vie ;)
avatar fred78 | 
[quote=Ziflame] Et ce Vladimir Vukićević devrait peut-être commencer par utiliser du Cocoa pour Firefox, au lieu d'utiliser du papier, carton, scotch et pritt pour l'interface de son browser... [/quote] On sent que tout ceci est issu de ta grande connaissance du développement Mac ainsi que du code de Firefox... Merci donc pour ce conseil avisé, à transmettre d'urgence aux gens de Mozilla.
avatar Ziflame | 
@ fred78 Comme le dit si bien lifenight, Firefox est en xul, c'est de l'xml pour interface graphique, en gros.
avatar cyberdog | 
L'interface de Safari sous Léopard est tout aussi nul !!!! cyberdog ! :-(
avatar Anonyme (non vérifié) | 
firefox en xul, firefox est nul ! (je blague hein) franchement, entre attendre un navigateur qui sera peut être éventuellement un jour aussi rapide que safari, et safari qui déjà au point, le choix est vite fait. (Et en plus, le code source ouvert, c'est pas dit que c'est un gage de sécurité... enfin bon... je dit ça, je dit rien...)
avatar grenoble | 
Par pitié les amis, arrêtez de vous improviser Grands Maîtres dans un domaine aussi expert. La sécurité apportée par l'opensource, ça fait des années qu'elle a démontré son efficacité alors un peu de décence. Quant à conclure qu'il ne faut pas utiliser FF parce qu'il est moins rapide de Safari et donc se limiter à Safari, c'est mal connaître l'internet et ses standards. En apportant une vraie réponse multi-plateforme, les développeurs web peuvent réellement se concentrer sur leur site et non patcher sans cesse leur code pour qu'il puisse être tout terrain. Et oui, il y a encore beaucoup de sites incompatibles avec Safari, il y en a même des incompatibles avec FF. Internet Explorer a un passif dingue, avec le nombre d'installations standard d'XP.
avatar gloup gloup | 
Ça ne s'arrêtera jamais ce débat sur l'interface de Firefox? C'est lourd à la fin! ^^ :( En tout cas, je suis impatient de tester la beta4, la beta3 était déjà très rapide. :)
avatar Gaolinn | 
@grenoble : -Que FireFox soit plus sécurisé que IE ou autre ne prouve pas que l'OpenSource soit plus sécurisé que le modèle fermé. Cela prouve seulement qu'il est mieux développé, cet argument est donc un non-argument. -Le fait que FF soit multi plateforme ne signifie en rien qu'il soit plus standard que les autres. Internet étant un standard hors plateforme le nombre de plateforme supporté par FF ne le rend pas plus conforme aux standards. Ex. FF ne passe pas le test de compatibilité ACID2 alors que Safari le passe bien, Safari est donc plus standard que FF alors qu’il était mono plateforme.
avatar Anonyme (non vérifié) | 
@Gaolin >> Cela prouve seulement qu'il est mieux développé d'ailleurs, qu'est ce qui est protégé aujourd'hui ? même le dvd crypté de de Villepin a été décodé...
avatar Anonyme (non vérifié) | 
Arg... "Cela prouve seulement qu'il est mieux développé" et encore ce n'est pas dit ;-)
avatar grenoble | 
@charlub: Euh merci de me relire, je n'ai jamais parlé de standards pour FF... J'attestais simplement qu'en retrouvant un navigateur assez largement diffusé sur plusieurs plateformes permettait de s'appuyer dessus pour rendre son site compatible. C'est ce qui se passait avec IE quand il était encore dispo sur Mac et le monde du web s'en accordait assez bien, on était loin des standards :) Au niveau de l'opensource, tu me limites à FF, alors que je disais que la sécurisation due à un code source accessible à tous avait largement fait ses preuves. Le temps de réponse à une faille détectée étant souvent supérieure au temps de la sortie d'un patch pour un logiciel propriétaire. Mais ce n'est pas une obligation (ou un gage), je te l'accorde.
avatar Anonyme (non vérifié) | 
Hum... oui, mais avec un code fermé, trouver des failles est certainement plus difficile qu'avec un code ouvert. merci de TE relire.
avatar Brewenn | 
Quelqu'un connaît il Radon ?
avatar Hurrican | 
@gaolinn Firefox 3, passe le test Acid2 sans problème. Il est autrement plus complet que Safari, et surtout, le nombre de sites compatibles Firefox est bien plus élevé. Arrêtez avec Safari. Firefox tourne correctement, dans tous les environnements. Safari, lui, est archi-nul en dehors d'OsX. La version Windows est carrément lamentable (plantogène, moche, lente, etc...). Bien sûr Firefox n'est pas Cocoa. Il ne pourrait pas être réellement multi-plateforme s'il était basé sur un code propriétaire. Quant à la sécurité, Safari a surtout pour lui qu'il ne tourne réellement que sur Mac.
avatar Brewenn | 
Sic: Safari, lui, est archi-nul en dehors d'OsX. La version Windows est carrément lamentable (plantogène, moche, lente, etc...). C'est souvent le cas des premières versions, mais s'améliorent au fil des versions.
avatar divoli | 
On peut toujours papoter, mais Safari n'a de "succès" que sur Mac. Et encore, certains ne doivent l'utiliser que parce qu'on leur dit que c'est une appli mieux "intégrée" à OS X, sans chercher plus loin... Alors que Firefox est de plus en plus apprécié sur toutes les plateformes de part ses qualités, y compris sur Mac...
avatar Hurrican | 
@Brewenn Safari est en version 3.0.4 sur Windows, ce n'est pas la 1ère, moi j'en ai testé 3 versions. Son [b]seul[/b] avantage est son lancement rapide.
avatar franster | 
Firefox 3 est une application Cocoa, Vladimir Vukićević le dit incidemment quand il parle des problèmes qui affectaient les Beta précédente mais pas firefox 2 : "The reason why Firefox 2 wasn't affected was that Fx2 was not a Cocoa app; it is a Carbon app, and as such was exempt from being subject to coalesced updates". Firefox 3 fait des progrès dans son intégration dans l'environnement mac il se sert par exemple du vérificateur orthographique de mac OS X.
avatar NikonosV | 
Ca en a tout l'air juste pour voir, j'ai un drag and drop d'une photo de firefox 3beta4 vers une appli du doc trop fort l'appli s'ouvre avec la photo ! seul Safari pouvait faire ça avant, aucun autre browser du marché ! même avec Camino qui se dit intégré au au mac ... cela dit j'adore la faible consommation cpu et mémoire de camino ! Safari par moment c'est un bouffeur de cpu !! ce que Camino ne fait pas Firefox 3beta4 bcp de progres en consommation ressources par rapport à la version 2 ! on verra la version finale j'espère qu'elle fera aussi bien que Camino ! ils sont de ne pas travailler main dans la main Camino et firefox, l'union fait la force
avatar _TZ_ | 
La réponse de David Hyatt est présente depuis ce matin sur le blog. En gros, Safari s'appuie sur des fonctions qui ne seront peut-être plus supportées à l'avenir, et ne sont donc pas documentées pour les développeurs hors-Apple. Son argumentation se tient : David Hyatt Feb 28th, 2008 at 1:24 pm The programmatic disabling of coalesced updates should not be public API. It's actually a very dangerous thing to do. We aren't really happy with that code in WebKit, but we had to do it to avoid performance regressions in apps that embedded WebKit. Technically it's wrong though, since we turn off the coalesced updates for any app that uses WebKit! This includes drawing they do that doesn't even use WebKit. As for the window display throttling, that was a pref designed for Safari (that we don't even use any more). It's not private or magic. It's nothing more than a pref that we can examine from Safari-land, so linking to that is just silly. ;) Many of the private methods that WebKit uses are private for a reason. Either they expose internal structures that can't be depended on, or they are part of something inside a framework that may not be fully formed. WebKit subclasses several private NSView methods for example, and it cost us many many man hours to deal with the regressions caused by the internal changes that were made to NSViews in Leopard. As you yourself blogged, there was a totally acceptable public way of doing what you needed to do. For any private methods we use that we think should be public, we (the WebKit team) file bugs on the appropriate system components. Many of these methods have become public over time (CG stuff in Leopard for example). Be careful when you dig into WebKit code, since we may continue to use the WK method even though it's not public API just because we need to work on Tiger.
avatar NikonosV | 
je sors quand même un carton orangé ! :o) avec firefox, le drag and drop, ça ne fonctionne qu'avec les applis Apple ! avec Safari, ca fonctionne avec toutes les applis !
avatar Anonyme (non vérifié) | 
Quelques petites précisions à ce sujet, de la part d'un Mozillien équipé de Mac (au bureau et à la maison). 1 - Firefox 3 est une application Cocoa 2 - Firefox 3 passe le test Acid2 3 - C'est en devenant une application Cocoa à l'occasion de la version 3 que Firefox a perdu énormément en performance alors qu'il aurait du en gagner. Ceci a été corrigé en utilisant les APIs cachés d'Apple. Apple les utilise pour Safari et aussi, je cite Dave Hyatt "to avoid performance regressions in apps that embedded WebKit" (pour éviter les régressions de performance pour les applications embarquant Webkit). Cela signifie que si Safari est plus rapide que ses concurrents, c'est grâce à ces API cachées. C'est dommage pour la plateforme Apple, et il faut aussi se souvenir qu'on a traîné Microsoft en juste pour moins que ça. Utilisateur Apple moi même depuis l'Apple ][+, via un Mac SE, un iMac et un Powerbook G4, j'espère de tout coeur qu'Apple sait se montrer plus élegant, y compris au niveau de la morale, que son concurrent de Redmond. 4 - Camino est basé sur Firefox. On devrait voir Camino profiter de la plupart des progrès réalisés par Firefox en terme d'utilisation mémoire, respect des standards et performances, une fois que Firefox 3 sera sorti. 5 - Tous les utilisateurs du Web, y compris ceux qui utilisent IE et/ou Safari bénéficient de l'apport de Mozilla qui, grâce à sa part de marché, force les auteurs de sites Web à plus respecter les standards et ne plus penser seulement à IE quand ils codent. Du coup, cela augmente les chances que leurs sites soient aussi compatibles avec Safari, et c'est tant mieux. Souvenons du temps où beaucoup de sites étaient incompatibles avec le Mac. Ce temps là n'est plus, et j'ai la faiblesse de croire que Mozilla y est pour beaucoup. 6 - Pour conclure : http://standblog.org/blog/post/2008/02/29/Firefox-3-Performance-and-Apple-hidden-APIs
avatar franster | 
"Ceci a été corrigé en utilisant les APIs cachés d'Apple" Non Tristan tu n'as pas du bien lire ce que dit Vladimir, il a appliqué ce que dit une "tech note" tout à fait publique d'apple pour corriger ces problèmes, et ensuite il s'est aperçu que safari avait sa propre méthode pour y accéder mais l'API en elle même n'était pas cachée.
avatar Frodon | 
@Hurrican "Safari est en version 3.0.4 sur Windows" Il ne manquerait pas un petit mot après 3.0.4?? Il me semble qu'il manque un mot commençant par B, se terminant par a et composé de 4 lettres en tout... ... Oui Beta, voilà!!! Ca veut dire quoi Beta déjà en informatique??? Instable!! Faire un jugement définitif sur Safari Windows comme tu le fais alors qu'il n'existe encore AUCUNE version STABLE de disponible, c'est un peu exagéré!!!
avatar Frodon | 
@nitot "je cite Dave Hyatt "to avoid performance regressions in apps that embedded WebKit" (pour éviter les régressions de performance pour les applications embarquant Webkit)." Cela veut surtout dire, cette partie du moins, que c'est fait au niveau du code dans Safari (et non au niveau du fichier .plist comme indiqué dans la tech note d'Apple), parce que le moteur de Safari est utilisé à l'interieurs d'applications tierces... Or si c'était fait dans la plist de Safari, les applications utilisant WebKit ne verrai pas les Coalesced Updates désactivé automatiquement (sauf si le développeur pense à le mettre dans le fichier .plist de son application) puisqu'ils n'héritent pas des préférences de Safari. Et donc perdrait en performance de rendu par rapport à Safari. Le faire dans le code permet de s'assurer que les performances soit aussi bonne que cela soit dans Safari ou lorsque WebKit est inclus dans une application tierce.
avatar Frodon | 
@franster Exact, on peut d'ailleurs lire dans le fichier Info.plist de la dernière nightly build de Firefox 3 l'entrée suivante: [quote=Info.plist extract] CGDisableCoalescedUpdates [/quote]
avatar fevre53 | 
et je voulais savoir l'intégration du trousseau c'est pour quand?

CONNEXION UTILISATEUR