Mozilla prépare un nouveau moteur de rendu pour Firefox. Baptisé Quantum, il est prévu pour la fin de l’année prochaine et s’appuiera sur les travaux de Servo et le langage Rust. L'éditeur a également décidé de se débarrasser de l'API Battery Status, dont l'utilisation était détournée.
Le web n’est plus statique, mais de plus en plus composé d’applications web et de pages dynamiques. Partant de ce constat, Mozilla a décidé de remplacer Gecko, son traditionnel moteur de rendu, par un nouveau venu : Quantum. Le but affiché est d’obtenir des performances nettement supérieures, et donc de charger plus rapidement les pages. Un navigateur moderne pour un web moderne, en quelque sorte.
Electrolysis, Rust et Servo pour préparer le terrain
L’annonce de Quantum est à lier avec d’autres travaux menés jusqu’ici, à commencer par Electrolysis. Il s’agit pour rappel de la technologie maison pour diviser Firefox en plusieurs processus, essentiellement deux en fait : le moteur de rendu dans l’un, le reste dans l’autre. L’objectif était de ne plus faire traiter par le même l’ensemble des calculs, le chargement d’une page lourde pouvant créer des latences dans l’interface. Résultat, un Gecko isolé dans son coin.
Il y a ensuite Rust, un langage créé par Mozilla et dont le succès augmente peu à peu. Il permet d’obtenir des performances proches du C et du C++, mais en offrant certains avantages traditionnellement liés aux langages de plus haut niveau, comme C# et Java. Il est orienté objet, concurrentiel et typé sûr. L’idée est donc d’avoir un code performant, tout en garantissant la sécurité des threads et en évitant les erreurs de segmentation.
Enfin, on trouve Servo. Derrière ce nom se cache un moteur de rendu entièrement écrit en Rust. Beaucoup espéraient qu’il s’agissait du projet menant au remplacement de Gecko. On sait maintenant que Servo sert de laboratoire d’essai, puisque le vrai prochain moteur en reprendra bon nombre de travaux.
Quantum, tourné vers le parallélisme des instructions et le GPU
Isolé, Gecko va donc être remplacé par Quantum, écrit pour une bonne part en Rust et incorporant plusieurs principes explorés par Servo. Mozilla indique revoir avec son projet la manière dont le moteur affiche une page, à un niveau fondamental. Par exemple, la manière dont les feuilles CSS sont appliquées, comment les opérations DOM sont exécutées et ainsi de suite.
L’accent sera particulièrement mis sur le parallélisme des instructions et sur la déportation d’une partie des calculs vers le GPU quand ce sera possible. Selon Mozilla, Quantum devrait permettre à Firefox d’améliorer la stabilité, la sécurité et la qualité générale de l’expérience de navigation. Surtout, l’éditeur est particulièrement confiant sur un point en particulier : le nouveau moteur permettra une augmentation significative des performances.
Un point qui constitue l’un des cœurs de la bataille entre les navigateurs, les utilisateurs souhaitant toujours des lancements instantanés et des chargements rapides pour les pages web.
Une première version en fin d'année prochaine
Mais Quantum ne va pas arriver d’un coup en tant que projet terminé. Une version initiale sera proposée en fin d’année prochaine, mais il y aura tout un chemin préparatoire. Mozilla a ainsi indiqué que Firefox va évoluer à travers une longue série de changements importants au cours de l’année qui vient. La généralisation d’Electrolysis en fait partie.
Pour l’instant, Quantum est prévu pour l’ensemble des plateformes supportées par Firefox, à l’exception d’iOS. Mozilla ne désespère pas pouvoir proposer une mouture pour le système mobile d’Apple, mais les navigateurs n’y ont actuellement pas le droit d’avoir leur propre moteur. Ils doivent en effet utiliser une vue déportée de Safari, Chrome et Firefox affichant donc exactement le même résultat. Linux, macOS, Windows et Android auront par contre bien leur mouture adaptée.
Firefox se débarrasse de l’API Battery Status
Le navigateur fera également l’impasse d’ici quelques mois sur une API dont beaucoup attendaient des merveilles. Battery Status devait en effet permettre aux développeurs de connaître l’état de la batterie sur un ordinateur pour éventuellement afficher des pages web moins gourmandes, donc plus économes en énergie, augmentant donc l’autonomie.
Dans la pratique, il semble que le seul véritable écho trouvé ait été chez les régies publicitaires. Le niveau de batterie est devenu en effet une variable parmi tant d’autres qu’il est possible de suivre au cours d’une navigation. En clair, un outil de tracking parmi tant d’autres. D’après les propres statistiques de l’éditeur, seuls 6 % des sites se servent de l’API, mais une minorité le ferait pour des raisons légitimes.
Même si elle n’est pas spécifique à Firefox (Chrome et Opera l’ont aussi), l’API sera quand même supprimée du navigateur avec la version 53, attendue le 6 mars prochain. Notez qu’Apple avait préparé le support de cette API dans Webkit, mais il n’a jamais été activé dans Safari. D’après les discussions sur ce point, les développeurs devraient eux aussi supprimer le code correspondant dans quelques jours, si aucune objection n'est faite.
Commentaires (75)
#1
J’ai hâte de voir ce que ça va donner…
Je suis un peu triste de voir que Mozilla a lentement mais surement perdu de sa superbe ces dernières années avec pas mal de projets qui partaient un peu dans tous les sens et un manque cruel d’idées (syndrôme des gens riches ?)
Mais il ne faut pas oublier que c’est quand même grâce à Mozilla qu’on a été “libéré” d’IE6 et tout le monde devrait lui en être reconnaissant. Les gens qui ont lancé ce projet à la mort de Netscape/AOL étaient des fous fourieux. Bravo à eux… que leur vie soit longue et douce.
#2
Code Quantum,
Boot to Quantum.
#3
Sans surprise si Microsoft ne propose rien d’équivalent d’ici là ce sera mon prochain navigateur. Un navigateur dans un langage safe mon rêve :)
" />
Par contre c’est bizarre ils n’ont pas perdu 50% de performances. Nous aurait t’on menti?
Le bound checking c’est au moins çà…
#4
#5
Dans la pratique, il semble que le seul véritable écho trouvé ait été chez les régies publicitaires. Le niveau de batterie est devenu en effet une variable parmi tant d’autres qu’il est possible de suivre au cours d’une navigation.
J’ai pas bien compris pourquoi les régies publicitaires sont intéressés par le niveau de la batterie de l’utilisateur, quelqu’un pour m’expliquer ?
#6
#7
#8
Ca sert à différencier les gens:
Entre Bob, geek sous Firefox et Alice, geek sous Firefox, il est fort probable que leur niveau de batterie à un instant T soit différent, donc ça sert à différencier ces 2 profils lors du tracking.
#9
Ca sert à différencier les gens: Entre Bob, geek sous Firefox et Alice, geek sous Firefox, il est fort probable que leur niveau de batterie à un instant T soit différent, donc ça sert à différencier ces 2 profils lors du tracking.
#10
#11
Pourquoi parler de “parallélisme des instructions” et pas simplement de parallélisme comme dans le papier de David Bryant en lien ?
L’ajout de “des instructions” rend le truc moins compréhensible. Il s’agit en fait de tirer partie des architectures multi-core des CPU, en ayant un navigateur multi-process.
#12
Mon humble avis : Mozilla devrait arrêter avec ses moteurs fait maison et passer sous Webkit.
" />
La raison est très simple : comment Mozilla peut espérer concurrencer WebKit avec son armée de développeurs (pro pour la plupart car travaillant chez Apple, Google…etc).
Enfin, je leur souhaite bonne chance tout de même
#13
L’aspect “safe” du Rust se fait à la compilation. Je ne saurais pas vraiment te l’expliquer précisément, mais le scope est très strict et par exemple, un passage de variable à une fonction retire cette variable du scope : elle n’appartient plus à la fonction “globale” mais à la fonction à laquelle elle a été passée. Du coup on fera plutôt un passage par référence. Et les variables sont, de base, constantes. Etc.
Tu as une performance moindre que en C/C++ mais c’est dû au compilateur jeune en partie.
Et du Rust a “les mêmes performances que du code C dans lequel on a fait du code safe”. En gros, il fait le boulot de faire du code safe à ta place alors qu’en C il faut te démerder.
#14
Bof, je dirais surtout que la libération concrête et réelle d’IE est arrivée quand Safari puis Chrome se sont développés sur mobile.
Mais du coup c’est aussi arrivé en même temps que Microsoft a développé IE 11 puis Edge.
#15
Über s’en ser(vai)t pour augmenter les prix il me semble (pas directement dans un navigateur, mais c’est tout comme). Puisque tu as tendance à commander ton taxi si ta batterie va mourir, quel qu’en soit le prix.
#16
Mozilla et Microsoft sont les derniers concurrents de webkit. Si on les supprime, ça donnera un web maîtrisé par un seul moteur de rendu avec les mêmes dérives qu’on a pu avoir avec IE (e.g. plus personne ne se fera chier à gérer autre chose que les balises spécifiques à webkit, donc tout nouveau concurrent devra se faire chier à être compatible).
#17
La securité de rust ne repose pas (a ma connaissance) sur du bound checking. En fait le model de securité est directement integré au langage. Une seule fonction (et donc un seul thread) peut prendre la main en lecture et/ou ecriture sur une variable, le langage interdit tout ce qui pourait ammener a des corruptions de mémoire. Toute la securité ou presque est faite a la compilation (par une verification statique) et donc sans perte de performance. Ce systemen n’est pas parfait et reste trop contraignant pour être utilisé tout le temps donc le langage comprend des blocs unsafe permetant de contourner momentanément le modele de securité (un certain nombre de choses son faisable d’un point de vue securité mais sont repéré par le compilateur comme dangereuses).
#18
Quand tu utilises le navigateur Tor, on te conseille de ne pas maximiser la fenêtre pour qu’“on” ne soit pas capable de te tracker avec ta résolution d’écran :)
Je te conseille d’aller voir ici : https://panopticlick.eff.org/ et de demander les infos complètes sur l’empreinte de ton navigateur. Oui, on peut te tracker avec les polices d’écriture embarquées dans ton navigateur ^^
#19
Oh Bravo !
" />
#20
Merci, t’as l’air de t’y connaître un peu mieux que moi ^^
#21
Oui et non.
WebKit a déjà pour philosophie de coller à la nome. A l’époque d’IE c’était la débandade, Microsoft n’en faisant qu’à sa tête.
Et puis WebKit ce n’est pas qu’une société, de grand noms le maintiennent, et si Mozilla et Microsoft s’y ajoutaient, on aurait le moteur par excellence (ce qu’il est déjà en fait).
#22
Bien d’accord, je continue de garder Firefox rien que pour ça, même si Chrome a un bel avantage en terme d’intégration..j’arrive pas à lâcher Firefox.
#23
Oui, exactement sachant que le cas des sites avec des balises spécifiques à Webkit/Blink est déjà d’actualité. J’imagine même pas sans les autres moteurs de rendu.
#24
j’ai juste regardé le langage un soir ou deux ^^
#25
Il y a toujours un risque que webkit dérive vers ce qu’était Microsoft.
Je préfère encore qu’une association galère à faire un moteur alternatif et qu’il ne soit utilisé que par 15% des gens mais qu’il y ait un peu de concurrence perso.
#26
#27
Ah parce que Google, Apple, Microsoft n’utilisent jamais de logiciels libres dans leurs OS et développent de A à Z leurs programmes en interne ? Je pense plutôt le contraire justement.
#28
Vincent Hermanna écrit :
Isolé, Gecko va donc être remplacé par Quantum, écrit pour une bonne part en Rust
N’importe quoi, Gecko ne va pas être remplacé par Quantum. Le projet Quantum est juste un amélioration de gecko sur 4 principaux points:
- Quantum DOM : les modifications du DOM seront traitées en parallèle.
- Quantum Compositor : les appel au drivers graphiques seront fait dans un processus séparé.
- Quantum CSS : remplace le moteur CSS par celui de Servo.
- Quantum Rendering : Le système qui s’occupe du rendu des éléments graphiques est remplacé par celui de Servo accéléré par GPU.
Bref c’est des parties très limitées de Servo qui vont être intégrées dans Firefox et une partie de travaux de Quantum ne concerne pas Rust.
La base du moteur reste toujours Gecko et heureusement Servo est encore très très loin d’être prêt pour le remplacer et il ne le sera probablement jamais. Il sert surtout de terrain d’expérimentation pour les futures technologies a intégrer a Gecko.
Pour ceux qui seraient intéresses par plus de détail :https://billmccloskey.wordpress.com/2016/10/27/mozillas-quantum-project/
#29
Je le sais bien mais mon post était ironique ;)
Microsoft a travaillé sur un os écrit complètement en code safe. Le langage M# utilisait aussi plusieurs concepts de rust. Il y avait aussi énormément d’optimisations pour le many core et le parallélisme massif. Sans compter les autres optimisations avec les sip permis par l’architecture de ce système. A l’époque plusieurs personnes ont refusé de croire qu’il était plus rapide que Windows car écrit dans un langage safe, donc plus lent. Pourtant tous les documents et témoignages allaient dans ce sens.
Actuellement Microsoft essaye de faire évoluer le C++ de la même façon
https://github.com/isocpp/CppCoreGuidelines
Plusieurs de ces concepts sont repris dans checked c:
https://www.microsoft.com/en-us/research/project/checked-c/
Je pense que ms va essayer de le proposer sur une future norme de C++ …
Sinon rust effectue bien du bound checking au runtime dans certains cas d’après ce lien:
http://stackoverflow.com/questions/28389371/why-does-rust-check-array-bounds-at-…
Mais les pertes de perfs restent minimes.
#30
Désolé mais je ne vois pas sur quelle partie de mon commentaire tu rebondis.
Peux-tu être plus claire stp ?
#31
Pour moi la libération d’IE6, c’est quand la part de marché des autres navigateurs a obligé les dev web à ne plus faire de “l’optimisé pour IE6”. Et ça c’est arrivé avec la popularité de Firefox, quand un dev a décidé de reprendre le moteur de la grosse suite Mozilla en virant tout ce qui ne relevait pas de la navigation web et en permettant les extensions.
Et ça date de bien avant Chrome.
Chrome a commencé en utilisant le moteur de Konqueror. Quand Chrome est sorti, ce moteur était capable d’afficher correctement tous les sites majeurs d’Internet, uniquement grâce au 20% de pdm de Firefox quelques années avant qui ont forcé les dev a faire du html correct.
#32
Effectivement, qu’il n’y ai qu’une seule norme technique est très important. Pourtant, ça n’empêche pas plusieurs systèmes de se concurrencer, et de s’entre-aider à l’occasion ou de se servir des avancées produitent par d’autres lorsqu’une solution fonctionne mieux ou est plus aboutie qu’une autre.
#33
#34
Android, MacOS : originaires du logiciel libre
Microsoft a collaboré avec Canonical pour une partie du développement de Windows 10
#35
Merci des explications et di lien !
Donc l’idée du projet quantum est de remplacer, petit à petit, l’ensemble des éléments de Gecko par ceux de Servo. Tout en conservant la base solide de Gecko.
Ça me rassure, parce que vu l’état d’avancement de Servo, je le voyais mal arriver d’un coup dans Firefox. Ça leur permettra du coup de bien séparer les éléments (au niveau du dév) et de les tester grandeur nature au fur et à mesure. Ça semble une bonne idée !
#36
#37
Ceci, par exemple.
#38
Ce n’est pas n’importe quoi, c’est ce que dit David Bryant dans l’article en lien que tu as cité :
And so, Project Quantum is about developing a next-generation engine that will meet the demands of tomorrow’s web by taking full advantage of all the processing power in your modern devices. Quantum starts from Gecko, and replaces major engine components that will benefit most from parallelization, or from offloading to the GPU.
En fait, vous dites quasiment la même chose.
Gecko est bien le moteur actuel de Firefox ? Quantum est bien le futur moteur de Firefox ?
Donc Quantum va bien remplacer Gecko.
Que Quantum parte Gecko au départ ne change rien.
#39
#40
Webkit/Blink, via Google et Apple principalement, ont (trop) souvent pour philosophie d’imposer leurs choix grâce à leur PDM et leur influence. (Par exemple : le préfixe -webkit- et beaucoup de web components ajoutés par Google ne sont pas un standard ou pas (encore) implémenté).
#41
#42
En vrai webkit est supporté par Apple, Nokia et Adobe. Google eux en on fait un fork “blink” (webkit est déjà un fork à la base de khtml) aidé de Opera, Intel et Samsung.
Du coup ça fait 4 moteurs concurent: blink, webkit, gecko/servo, trident/edge
A savoir que Samsung travaille aussi sur Servo.
En vrai, même si ça semble simplifier le travail (tout le monde travaille sur le même projet), au bout d’un moment il y a toujours une divergence sur certains aspects (organisation, technologies, etc.) qui font que certains industriels préfèrent prendre une voie à part (ce qu’à fait Apple à l’origine de khtml avec webkit, ce qu’à fait Google de webkit avec blink).
Avoir un large choix de moteur permet aussi d’en changer quand celui qui est utilisé devient trop compliqué ou dépassé : Opéra utilise maintenant Blink à la place de Presto, Microsoft utilise Edge à la place de Trident, Mozilla va utiliser Servo à la place de Gecko…
Plus d’infos :https://en.wikipedia.org/wiki/Comparison_of_web_browser_engines
#43
#44
#45
j’ai hâte de voir ça !
#46
Je n’y crois pas trop les gains sont trop importants, notamment au niveau sécurité. Par contre je suis d’accord que ça prendra beaucoup de temps. A mon avis c’est surtout plus simple à faire évoluer de façon incrémentielle que de partir sur un reset complet qui créerait une totale rupture et tous les problèmes qui vont avec.
Microsoft a adopté la même stratégie incrémentielle avec Midori pour intégrer les changements dans Windows 10.
#47
Dommage qu’Opera ait abandonné Presto… C’était plus possible à maintenir comme zinzin ?
#48
Au vu des benchmarks de Servo, celui-ci surclassait Webkit de loin. Alors pourquoi Mozilla devrait rejoindre les rangs de Webkit alors qu’ils vont proposer un moteur bien meilleur, développé avec des paradigmes modernes (là où Webkit se traine tout son historique) ?
Surtout que si on transpose ta remarque dans un autre registre (attention au grinçage de dent) :
“Comment les développeurs de Linux peuvent espérer concurrencer Windows avec son armée de développeurs pro pour la plupart.”
Je pense que cette formulation doit bien faire rire, et la réponse est triviale : pour proposer une alternative -> dans le cadre des navigateurs internet, la réponse est la même.
Si tu n’as pas de concurrence, tu ne te remets pas en cause (ou très rarement).
#49
#50
Ou ça peut etre tracké par les régies, pour les bonnes raisons : diffuser un pub plus légère à jouer en cas de manque de batterie.
Aucun moyen de le savoir.
#51
La régie publicitaire qui vous veux du bien ?
" />
Alors là j’ai comme un doute
#52
#53
Oh bravo…
#54
#55
Firefox
" /> Bientôt de retour pour écraser les autres mouchards made in M$ et Google. 
" />
#56
mais si, pub plus légère pour consommer moins de batterie, du coup ils peuvent t’en balancer encore 2 ou 3 de plus avant que tu sois en rade ^^
#57
#58
#59
En pratique, Webkit n’est déjà plus utilisé sur Chrome, nous avons donc 4 navigateurs (Chrome, Edge, Firefox & Safari) avec 4 moteurs différents (Blink, EdgeHTML, Gecko & Webkit).
Du coup, aucune raison valable pour Firefox de se rapprocher d’un moteur et donc d’une multinationale particulière au risque de perdre de son indépendance.
#60
#61
C’est ce qu’on disait aux dev KDE concernant Khtml il y a qq années…
“Pourquoi vous passez pas à Gecko ?”
Et puis finalement, Apple (ou google? j’ai un doute maintenant) a eu besoin d’un moteur HTML ouvert,… tu connais la suite…
Difficile de savoir comment tournera l’avenir de la concurrence. Par contre, facile de savoir comment tourne l’absence de concurrence.
#62
#63
C’est bien ce qu’il me semblait. Merci de la confirmation.
#64
#65
#66
#67
#68
Toujours la même histoire avec Mozilla… Attendez Servi, ça va être génial. Ha non, en fait on change de plan, attendez Quantum, c’est révolutionnaire… Du vent sur du vent, et ça s’étonne de tomber à 9% de pdm.
#69
#70
Esperons que cela ne fasse pas comme avec le moteur de Redu Gecko entre 1998 et 2000
3 ans de developpement, en nom de code Mariner, Netscape 6 hyper bugué qui a fait fuir les 20% restants
sous Netscape..
#71
#72
#73
#74
(commentaire à supprimer, sorry, j’ai posté au mauvais endroit)
#75
Quand vont-ils enfin abandonner les navigateurs ? On n’a pas besoin d’eux. Avant il n’y avait qu’un seul navigateur avec Windows mais depuis Windows 10 il y en a déjà 2 de fournis on a donc l’embarras du choix ! Pas besoin d’un troisième navigateur !