Electrolysis : le multiprocessus de Firefox joue à cache-cache

Electrolysis : le multiprocessus de Firefox joue à cache-cache

When it's done

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

12/02/2016 7 minutes
18

Electrolysis : le multiprocessus de Firefox joue à cache-cache

Firefox se prépare à recevoir une technologie utilisée actuellement dans ses versions mobiles et permettant de faire défiler une page de manière parfaitement fluide, même en cas de nombreux scripts. Derrière cette technique, nommée APZ, se profile un projet au long cours : Electrolysis.

C’est un billet sur l’un des blogs de l’éditeur qui a lancé les interrogations. Mozilla y annonce en effet que Firefox 46 sera doté d’une technique nommée APZ, pour « Asynchronous panning and zooming ». Initialement, l’APZ a été créé pour les versions mobiles de Firefox, qui obéissaient à des contraintes supplémentaires, notamment celle de ne jamais faire perdre le sentiment de réponse tactile.

Le but premier de l’APZ est de fournir un grand sentiment de fluidité. L’utilisateur peut ainsi descendre dans la page sans attendre qu’elle soit complètement chargée. La technique montre son efficacité sur les sites particulièrement chargés en scripts. Ces derniers ont une fâcheuse tendance à bloquer le chargement d’une page, transformant le glissement vers le bas en une série de saccades du plus mauvais effet. Et donnant bien sûr le sentiment que le navigateur est poussif.

Le traitement des évènements utilisateur par un autre processus

Dans son billet, Mozilla explique que les évènements de contrôle par l’utilisateur (gestes tactiles, clics, molette) sont le plus souvent traités par les navigateurs dans le même processus central qui gère déjà l’affichage des pages. Ces évènements sont pris dans la masse et peuvent donc être repoussés le temps qu’un traitement particulier se termine. D’où les à-coups. C’est précisément ici qu’entre en piste un projet sur lequel travaille Mozilla depuis des années : Electrolysis.

Beaucoup se souviennent de ce nom qui était synonyme, il y a déjà des années, de processus multiples. Appliqué au cas d’APZ, le principe serait donc de gérer les évènements utilisateur dans le processus principal, alors qu’un autre s’occuperait de la composition, c’est-à-dire d’afficher les pages. Deux processus clairement séparés et pouvant d’autant mieux traiter les tâches séparément qu'ils proposent depuis longtemps maintenant plusieurs cœurs d’exécution. Plus précisément, le traitement des évènements est envoyé à un processus enfant en court-circuitant tous les autres calculs.

firefox apz

Tout a un prix

De là, il existe de nombreuses remarques à faire. La première est que la technique APZ, si elle fournit un vrai sentiment de fluidité, n’est pas non plus miraculeuse. Elle ne peut pas aller plus vite que la musique : si l’utilisateur descend dans une page dont le chargement n’est pas terminé, il ne rencontrera que des espaces vides, avec une couleur unie ou non.

Ces espaces seront ensuite complétés au fur et à mesure que le processus de composition terminera son travail. Un phénomène connu sous le nom de « checkerboarding » et dont Mozilla ne cherche pas à masquer l’existence. L’éditeur explique cependant que ce phénomène, inévitable, peut être assez largement maîtrisé et réduit à des très courts délais dans l’affichage.

L’autre problème réside dans le nom même de la technique : le phénomène d’asynchronisme. Cela signifie qu’il existe obligatoirement un délai, même si minimal, entre l’action de la molette par exemple et la perception du mouvement effectué à l’écran. Pour que le délai ne se voit pas, il faudrait idéalement qu’il n’y ait pas plus de 33ms d’écart, soit deux images dans un rythme de 60 par seconde.

Mozilla indique qu’il existe plusieurs techniques pour éviter complètement ce délai en utilisant le positionnement CSS plutôt que du JavaScript. L’éditeur fournit d’ailleurs une série d’exemples sur une page dédiée aux effets de défilement de pages.

La preuve de l'arrivée d'Electrolysis ?

L’un dans l’autre, il semble que le prix à payer pour que l’APZ puisse fonctionner ne soit pas si coûteux. Pourtant, cette technique dépend intrinsèquement d’Electrolysis (donc de la séparation des processus), et c’est ici que les choses se corsent. Mozilla travaille sur ce projet depuis des années sans l’avoir encore intégré dans la branche principale.

Pendant longtemps, il fallait passer par le dossier « e10s » du FTP de développement pour récupérer des versions spéciales. Désormais, on le trouve dans les Nightlies et la Developer Edition de Firefox 46. Cela signifierait-il du coup qu’Electrolysis arrive enfin pour tout un chacun ? Malheureusement non.

Mozilla confirme qu'Electrolysis n'est pas encore prêt

Curieux de voir cette technologie annoncée comme une simple fondation d’APZ et une arrivée pour Firefox 46, nous avons posé la question à Mozilla. Il nous semblait effectivement qu’après tant d’années, l’arrivée se serait faite en fanfare. Et effectivement, l’éditeur nous a répondu que ni Electrolysis, ni APZ n’étaient véritablement prévus pour cette version précise du navigateur. Le billet de blog, tel que rédigé actuellement, induit donc en erreur.

Nick Nguyen, vice-président des produits chez l’éditeur, nous a ainsi indiqué : « Mozilla travaille sur le projet d’utiliser de multiples processus dans Firefox. Le multiprocessus améliore les performances en exploitant mieux les processeurs à cœurs multiples. Cette technologie est disponible aux utilisateurs dans nos canaux de préversion (Nightlies et Developer Edition) depuis août dernier. Nous continuons actuellement à tester le multiprocessus dans ces canaux, tout comme dans Firefox bêta, en commençant avec des utilisateurs sélectionnés. Nous continuerons à tester les performances et la stabilité avant de diffuser la fonctionnalité aux autres utilisateurs ». Quant à l’APZ, il est accompagné du même descriptif que pour Electrolysis.

Actuellement, si on installe et teste la Developer Edition de Firefox 46, Electrolysis et APZ sont activés par défaut. Dans les options générales, il existe d’ailleurs une case spécifique, intitulée « Activer le mode multiprocessus ». Mozilla nous explique cependant qu’en l’état actuel des choses, la fonctionnalité n’est pas assez rodée pour certifier qu’elle débarquera dans Firefox 46 : « les fonctionnalités ne sont validées que sur leur qualité et ne sont pas liées à une version spécifique, nous ne pouvons donc pas promettre une version précise jusqu’à ce que nous soyons satisfaits ». Ce qu’ils ne sont pas.

firefox electrolysis developer

Encore de nombreux tests

Mozilla nous a par ailleurs indiqué que le billet de blog allait être mis à jour, puisqu’il induit en erreur. Oui Electrolysis (et dans une moindre mesure APZ) remonte tout doucement vers la surface, mais il faudra encore patienter plusieurs mois au moins. Mais Mozilla commence doucement à en reparler de manière un peu plus appuyée. Il faudra par contre que l’éditeur rende sa communication plus cohérente : la page du wiki de Mozilla réservée à Electrolysis mentionne bien son activation pour la version 46 finale, avec une phase d’A/B testing pour les bêtas depuis plusieurs versions (43, 44 et 45).

Dans tous les cas, les deux technologies peuvent être testées par ceux qui récupèreront la dernière Developer Edition. Cela intéressera probablement les créateurs d’extensions car certaines risquent de poser problème avec une telle séparation des processus.

18

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le traitement des évènements utilisateur par un autre processus

Tout a un prix

La preuve de l'arrivée d'Electrolysis ?

Mozilla confirme qu'Electrolysis n'est pas encore prêt

Encore de nombreux tests

Commentaires (18)


C’est fou tout le travail qui est déporté sur les navigateurs parce que les dev webs font n’importe quoi <img data-src=" />


Mouais… enfin je me déplace énormément dans les pages avec le bouton 3 de la souris et je suis sur Firefox depuis pas mal d’années.



Ca ne fait que quelques mises à jours que le défilement est imbouffable sur FF de cette manière tant que la page n’est pas finie de charger. Néanmoins, ça ne pose pas ce problème avec la molettes (ou pour plus de fluidité avec le slider).



Je précise que ça me le fait sur plusieurs ordinateurs (boulot, maison…) et que je croise les doigts à chaque mise à jour pour que ça soit corrigé.



De là à dire qu’il faut un système importé de la version mobile pour que ça aille mieux, alors que ça ne posait pas de problème il y a quelques mises à jour… je trouve ça bizarre <img data-src=" />


La réciproque est tout autant vraie au passage. <img data-src=" />


Et pendant ce temps Firefox est le seul browser a ne pas être sandboxé … et qui cherche à ressembler de plus en plus à Chrome. Au final, autant utiliser chromium !


Essaye avec la Developer Edition de Firefox qui est en 46, peut-être que le défilement s’est déjà amélioré sur cette version.

En plus le thème minimaliste de cette version est tellement plus sympa que l’imitation officielle et chinoise de Chrome .


Jamais de problème de scrolling moi








marba a écrit :



C’est fou tout le travail qui est déporté sur les navigateurs parce que (les dev webs font) les clients décident n’importe quoi <img data-src=" />





Fixed <img data-src=" />





L’éditeur fournit d’ailleurs une série d’exemples sur une page dédiée aux effets de défilement de pages.





Pas trouvé sur leur site <img data-src=" />


Le thème de Firefox 46 est en tout cas bien mieux que l’actuel…



Et pour le boulot sur les navigateurs, c’est aussi parce que tant les technos HTML que JS n’ont jamais été conçues pour l’usage qu’on en fait. Et ça explique aussi pourquoi les IHM en HTML/JS sont si difficiles à maintenir (et qu’on change si souvent de frameworks dans le domaine).



Enfin bon le dév web côté client ce sont des bouts de ficelles et ce n’est hélas pas près de changer… :‘(


Je ne peux qu’être d’accord… Dans ma boîte on fait tout ce que demande le client… comme continuer le support IE8 ce qui alourdi à mort le code à cause de vieux IE. Ça serait bien plus performant (beaucoup de JS en moins et une façon de code différente) si on n’avait pas le support des anciens navigateurs morts.


C’est pas parce que ce n’a pas été prévu pour que ça ne peut pas le devenir. Je joue actuellement à un jeu et j’ai été support de voir qu’il était en HTML5. Ça reste un jeu 2D, avec plein d’effet, et ça rame pas d’un pète quand un autre de mes jeux lui en Flash saccade bien. Ça veut dire qu’ils arrivent aujourd’hui à faire mieux que l’AS3 avec asm.js et co. Et d’après ce que j’ai lu entre Flash 14 et V8 (Chrome) il y a un an, il y avait un facteur 2 en faveur du JS.



Le problème actuelle de la lenteur de JS n’est pas le JS, mais le DOM. Surtout sous Firefox qui est 10× plus lent que celui de Edge ou Chrome, d’où cette impression de lenteur du JS alors que c’est celle du rendu. Peut-être que le fait de supporter toujours XP y est pour quelque chose….


Mode ironie [on]

&nbsp;Rigolo: Ce samedi matin, 8h45, quand j’ai lu cette news, je suis resté 1mn30 avec la phrase “chargement des commentaires” avant de voir enfin les 11 commentaires apparaître! D’habitude, cet affichage ne demande qu’une demi seconde.

C’est un petit effet pour appuyer l’article ?

Mode ironie [off]

je suis toujours sous XP pour mes connexions internet. Ce que sous-entend zefing , c’est que je ne pourrais plus naviguer si je passais sous Chrome ou Edge ? plus de précision, please…


Windows XP est mort depuis avril 2014, continuer à l’utiliser est une hérésie teinté de sado-masochisme!



Edge n’existe pas sur cette version de Windows et Chrome a annoncé que Windows XP ne sera plus supporté dans quelques mois. Dit autrement si cela ne fonctionne plus, les développeurs considéreront que ce n’est pas de leur ressort.

Mozilla n’a pas précisé son intention au sujet de Windows XP, mais cela ne durera pas.


&nbsp;







Graphico a écrit :



Mode ironie [on]

&nbsp;Rigolo: Ce samedi matin, 8h45, quand j’ai lu cette news, je suis resté 1mn30 avec la phrase “chargement des commentaires” avant de voir enfin les 11 commentaires apparaître! D’habitude, cet affichage ne demande qu’une demi seconde.

C’est un petit effet pour appuyer l’article ?

Mode ironie [off]

je suis toujours sous XP pour mes connexions internet. Ce que sous-entend zefing , c’est que je ne pourrais plus naviguer si je passais sous Chrome ou Edge ? plus de précision, please…





&nbsp;Edge n’existe pas sous windows xp, seulement sous windows 10 (et 8.1 ?) pour chrome il fonctionne sous windows xp 32 bits d’après le site de Google. (edit: voir la réponse de Soriatane)

&nbsp;



zefling a écrit :



C’est pas parce que ce n’a pas été prévu pour que ça ne peut pas le devenir. Je joue actuellement à un jeu et j’ai été support de voir qu’il était en HTML5. Ça reste un jeu 2D, avec plein d’effet, et ça rame pas d’un pète quand un autre de mes jeux lui en Flash saccade bien. Ça veut dire qu’ils arrivent aujourd’hui à faire mieux que l’AS3 avec asm.js et co. Et d’après ce que j’ai lu entre Flash 14 et V8 (Chrome) il y a un an, il y avait un facteur 2 en faveur du JS.



Le problème actuelle de la lenteur de JS n’est pas le JS, mais le DOM. Surtout sous Firefox qui est 10× plus lent que celui de Edge ou Chrome, d’où cette impression de lenteur du JS alors que c’est celle du rendu. Peut-être que le fait de supporter toujours XP y est pour quelque chose….





Tout le monde se plaint de l’acces dom dans firefox mais d’expérience quand on a des dom très lourds(comme un select avec 200.000 options ) Firefox s’en sort bine mieux que chrome.



De même si on n’utilise pas innerHTML pour écrire du dom mais l’api dédié (createNode et appendChild) Firefox est très rapide ( même si un peu moins que chrome). Le problème n’est la vitesse du navigateur mais le code que pondent les développeurs web (peut être pour des problèmes de compatibilité avec des vieux IE ou a cause de la pression du client a sortir des trucs très vite a moindre couts)



Merci aux commentaires, je viens de comprendre pourquoi Firefox a du mal à scroller sur les pages depuis quelques semaines. C’est triste de voir son navigateur régresser sur certains points, on dirait que je tourne sur un vieux PC des fois.








Vesna a écrit :



Merci aux commentaires, je viens de comprendre pourquoi Firefox a du mal à scroller sur les pages depuis quelques semaines. C’est triste de voir son navigateur régresser sur certains points, on dirait que je tourne sur un vieux PC des fois.







tu es sur d’avoir bien compris que c’est un problème qui touche uniquement la version 46 qui en est au stade de developer edition / nightly???



L’accès au DOM n’est pas un problème, le reflow qui en découle l’est beaucoup plus lors du modification de rendu. Du coup, Firefox s’en sort bien mieux côté JS, mais dès que cela passe pas l’affichage, Firefox est juste 10× plus lent…. Le problème, c’est à ce niveau, s’il y a beaucoup de changement dans le rendu ça ne devient carrément plus négligeable. On se retrouve avec une rendu fluide suis Chrome quand il saccade sous Firefox. Et ce que ce soit sous Linux ou Windows 7. Après, je ne connais pas assez bien ce qui pourrait bloquer. En tout cas, je suis un bug sur la mise à jour de Cario depuis plus de 3 ans , et à part de mise à jour du numéro de version vers lequel le moteur devrait migrer, je ne vois riens.


Firefox a bon dos je pense ( dans le cas précis des commentaires)

J’ai signalé ce problème de chargement des commentaires ( qui est intermittent )

Et avant de le signaler j’ai vérifié , et le problème se manifestait sur IE sur Chrome et sur Firefox

Perso je penserais plus à un pb d’indexation de base ou un truc du genre



Dans tous les cas je suis en train d’arrétter d’utiliser FF pour des raisons d’affichage qui ne fonctionne pas bien

Ce n’est pas nécessairement la faute de FF , c’est peut-être la faute des pages web elles même mais si systématiquement une page fonctionne sur IE ou Chrome et pas sur FF, ben au bout d’un moment je laisse tomber ( les caractères d’un titre qui écrasent à moitié un autre ou une zone sélectable )