Mozilla devrait lancer une première alpha de son moteur de rendu Servo en juin

Mozilla devrait lancer une première alpha de son moteur de rendu Servo en juin

Oui, mais avec quel avenir ?

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

16/03/2016 3 minutes
16

Mozilla devrait lancer une première alpha de son moteur de rendu Servo en juin

Mozilla travaille sur un nouveau moteur de rendu à titre expérimental depuis plusieurs années. Baptisé Servo, son avenir est assez incertain. L’éditeur a cependant indiqué qu’une première alpha exploitable devrait être proposée en juin.

Servo est initialement un projet expérimental de Mozilla pour créer un nouveau moteur de rendu partant sur des bases modernes. Pour développer ce composant essentiel aux navigateurs, l’éditeur a même développé un langage pour l’accompagner, Rust, dont nous abordons parfois les nouveautés au fur et à mesure des versions.

Un moteur centré sur le parallélisme des traitements

Servo n’a jamais été vraiment conçu pour remplacer Gecko dans Firefox, ou même pour créer un tout nouveau navigateur qui viendrait supplanter l’actuel. Il permet simplement à Mozilla de travailler le rendu web en maximisant le parallélisme des instructions pour les différents calculs, qu’il s’agisse du rendu de la structure d’un site, de la décompression des images, du parsing du code ou encore du traitement des entrées utilisateurs (clavier, souris…).

Si ce projet rappelle des souvenirs, c’est probablement qu’il sert de terrain d’essai pour certains travaux effectués sur Electrolysis, une branche particulière de développement de Firefox. Comme nous le rappelions encore récemment, il s’agit d’un découpage de Firefox en plusieurs processus pour traiter chacun des opérations particulières. Le navigateur est actuellement le seul à ne pas diviser de cette manière le travail à accomplir.

Une première alpha en juin

Or, alors que le développement de Servo était relativement mystérieux, on apprend que l’éditeur vise une première alpha exploitable dans trois mois. La nouvelle a été annoncée par le développeur Paul Rouget, qui s’est empressé d’expliquer qu’il s’agirait d’un matériau assez brut, à savoir le moteur accompagné d’une interface très simple en HTML. Il a indiqué que le résultat ne pourrait clairement pas être utilisé au quotidien.

Le but sera évidemment de collecter des bugs et d’obtenir une première série de retours. Cela étant, le ton laisse à penser que Servo pourrait s’avancer vers un produit plus stable et plus accessible, le temps faisant son lent ouvrage. Patrick Walton, chercheur chez Mozilla, indique pour sa part que la compatibilité web est « une longue route ».

Lors de sa sortie, il ne faudra pas s’attendre à pouvoir naviguer sur l’ensemble de ses sites habituels. De nombreux accidents de rendu seront sans doute de la partie. Pour l'instant, tout l’intérêt est de tester les performances de Servo, puisqu’il s’agit de son orientation première. Rendez-vous en juin donc, pour une préversion de ce qui pourrait bien être, finalement, le futur moteur de Mozilla.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un moteur centré sur le parallélisme des traitements

Une première alpha en juin

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (16)


charon.G
Le 16/03/2016 à 07h 50

Ce que je trouve surtout intéressant est que rust n’est pas sensible aux failles de type buffer overflow. Ecrire un moteur de rendu dans ce langage c’est juste énorme au niveau sécurité.


psikobare
Le 16/03/2016 à 09h 04

voilà à quoi cela ressemblerais



servo combiné à webrender (un moteur de rendu conçu comme un moteur graphique de JV! détails techniques, test de perf est vraiment impressionnant



Il peut déjà afficher la plupart des sites simples (wikipedia), mais il reste encore énormément de travail avant que servo ne puisse gérer correctement toutes les nombreuses propriétés css du web


zefling Abonné
Le 16/03/2016 à 09h 45

Perso je ne vois pas trop de mystère : https://blog.servo.org/ <img data-src=" />


Uther Abonné
Le 16/03/2016 à 11h 55







charon.G a écrit :



Ce que je trouve surtout intéressant est que rust n’est pas sensible aux failles de type buffer overflow. Ecrire un moteur de rendu dans ce langage c’est juste énorme au niveau sécurité.





&nbsp; Ça va beaucoup plus loin que ça. S’il s’agissait de faire systématiquement vérifier le buffer overflow, c’est faisable avec C++.

&nbsp;

Par défaut, Rust s’assure que le programmeur respecte des règles qui garantissent la sécurité mémoire. Cela empêche complètement certaines catégorie d’erreurs comme les double libérations, utilisation de ressource libérés, invalidation d’itérateurs, accès concurrent aux données …

&nbsp;

&nbsp;



Uther Abonné
Le 16/03/2016 à 12h 12



&nbsp; Article :



&nbsp;Si ce projet rappelle des souvenirs, c’est probablement qu’il sert de terrain d’essai pour certains travaux effectués sur Electrolysis, une branche particulière de développement de Firefox.




&nbsp;Pas vraiment, les objectifs de parallélisme et les technologies employées sont assez différentes entre Servo et Electrolysis.       







&nbsp;Servo vise avant tout a paralléliser le moteur de rendu en effectuant les opérations de mise en forme et de dessin de la page web sur le plus de cœurs possible en même temps. Le but est d'optimiser le temps brut d'affichage d'une page ce qui permet plus de rapidité et réduit la consommation sur mobile.       







Electrolysis ne va pas du tout dans ce sens là. Il vise a séparer différents élément dans des processus séparées pour limiter les interactions entre les différents éléments du navigateur évitant ainsi qu'une erreur ou un ralentissement sur l'un, ai d'impact sur l'autre.

Lordtoniok
Le 16/03/2016 à 12h 19

Non il ne ressemblera pas vraiment à ça. Là ce que tu montres c’est servo tout seul, ce qui est annoncé en toute première alpha pour juin c’est le combo servo + browser.html.

browser.html c’est l’interface du navigateur tout en html/css/js. Et ça c’est assez sympatoche. Il y a quelques vieilles vidéos qui trainent par-ci par-là de ce projet. Une des plus représentatives des possibilités :https://www.youtube.com/watch?time_continue=41&v=IBzrCmGVDkA


charon.G
Le 16/03/2016 à 12h 30







Uther a écrit :



Ça va beaucoup plus loin que ça. S’il s’agissait de faire systématiquement vérifier le buffer overflow, c’est faisable avec C++.





Bien sur que non c’est au développeur C++ de le gérer explicitement. Après on a déjà débattu sur le sujet. Dans un projet classique basé uniquement sur des framework récents et surtout qui n’utilise aucune api système tu peux effectivement te passer de pointeurs ou contrôler tes ressources avec des pointeurs intelligents. Dans mon cas personnel, je suis en train de reprendre un projet système c’est totalement illusoire. La GSL qui est sortie récemment aide bien mais j’emploie beaucoup d’api systèmes qui manipulent essentiellement des pointeurs. Si les api win32 sont mal employés tu peux très bien te taper un buffer overflow. Je ne parle même pas de deviceiocontrol(ioctl sur unix) qui manipule des buffers non typés pour communiquer avec les drivers kernel mode. Certaines structures ont plusieurs couches de pointeurs et peuvent changer selon la version de l’OS. Selon la version de l’OS ou comment le driver va manipuler les données que tu envoies ça peut finir mal…..

Je suis aussi obligé de lire certaines structures binaires spéciales ou seul l’arithmétique de pointeurs fonctionne.







Uther a écrit :



Par défaut, Rust s’assure que le programmeur respecte des règles qui garantissent la sécurité mémoire. Cela empêche complètement certaines catégorie d’erreurs comme les double libérations, utilisation de ressource libérés, invalidation d’itérateurs, accès concurrent aux données …





Un langage type safe et memory safe moderne en fait. Rust est dans la lignée des langages natifs safe comme M# ou checked C. M# aussi s’attaque fortement au parallélisme et aux problèmes d’accès concurrents.



Uther Abonné
Le 16/03/2016 à 12h 34

Le projet a pas mal changé depuis ta video. L’image sur le dépot du projet donne maintenant plutôt ça: https://github.com/browserhtml/browserhtml/raw/master/browser.gif



&nbsp;Visiblement il n’essaye plus d’imiter l’interface de Firefox.


Uther Abonné
Le 16/03/2016 à 12h 44







charon.G a écrit :



Bien sur que non c’est au développeur C++ de le gérer explicitement.





&nbsp;Ce que je voulais dire contrairement au reste de Rust, c’est que c’est un contrôle assez simple et qui est faisable sans changer le langage.

&nbsp;Il me semble que certains compilateur le proposent en option.

&nbsp;





&nbsp;charon.G a écrit :



Un langage type safe et memory safe moderne en fait. Rust est dans la lignée des langages natifs safe comme M# ou checked C. M# aussi s’attaque fortement au parallélisme et aux problèmes d’accès concurrents.





&nbsp; Sauf que le projet Midori a été abandonné par Microsoft, on ne verra donc probablement jamais le M#.



charon.G
Le 16/03/2016 à 12h 51

En fait ce n’est pas exactement vrai. Midori a été abandonné car il était totalement incompatible avec Windows à tous les niveaux.

Le travail de M# a été repris pour un nouveau langage censé être compatible avec le c++: le checked C

Au sein du projet wavefront ils sont en train de réécrire une grande majorité de la base de code windows vers ce langage. Sur le peu d’informations qu’on a on sait que certains morceaux de edge seraient déjà écrit dans ce nouveau langage.

Ils travaillent aussi sur un projet nommé autobahn qui permettrait la conversion de code C++ vers ce langage.


charon.G
Le 16/03/2016 à 13h 01







Uther a écrit :



Ce que je voulais dire contrairement au reste de Rust, c’est que c’est un contrôle assez simple et qui est faisable sans changer le langage.

 Il me semble que certains compilateur le proposent en option.





Si on utilise certaines api (genre sprintf_s) tu dois parler de ca. Quand tu manipules des pointeurs le compilateur ne connait pas la taille des données. Au pire ce qui se passe l’appli ferme mais l’etat mémoire du processus est compromis. Il y a en effet des technos au sein de l’os qui permettent de détecter certains buffer overflow mais pas tous. Si c’était aussi simple que tu le dis on ne verrai plus de news sur NextInpact sur les failles de sécurité dans les navigateurs web. Je serai le premier à utilise cette méthode si une telle chose existait. C’est juste impossible à faire avec c++.



Uther Abonné
Le 16/03/2016 à 13h 05

Interessant, je n’avais pas entendu parler de ça.

&nbsp;Tu as des sources? Parce que je n’ai rien trouvé sur ce Checked C.


charon.G
Le 16/03/2016 à 13h 15
psikobare
Le 16/03/2016 à 13h 39







Lordtoniok a écrit :



Non il ne ressemblera pas vraiment à ça. Là ce que tu montres c’est servo tout seul





en fait c’est servo+webrender (ce que je voulais montrer)



je ne visait pas montrer browser.html je n’avais rien sous la main (maintenant oui, merci)







Uther a écrit :



Le projet a pas mal changé depuis ta video. L’image sur le dépot du projet donne maintenant plutôt ça: https://github.com/browserhtml/browserhtml/raw/master/browser.gif



 Visiblement il n’essaye plus d’imiter l’interface de Firefox.





merci aussi



Qu’est ce que c’est top, NXi, quand les commentaires sont posés, argumentés et constructifs comme ici <img data-src=" />


Uther Abonné
Le 16/03/2016 à 16h 13

Je pensais en fait aux tableaux, dont le compilateur peu connaitre la taille. En effet si on fait de l’arithmétique sauvage sur des pointeurs, il n’y a aucun moyen de controler qu’il n’y a pas de dépassement.