Seize tuiles, et deux façons de les animer
Le jeu est le prétexte. Ce que cette page démontre est le coût d'une animation, et il se mesure ici même : le bouton sous le plateau bascule entre deux implémentations du même déplacement, l'une confiée au compositeur, l'autre qui refait une mise en page à chaque image. Le relevé se fait dans votre navigateur, sur votre appareil, pendant que vous jouez.
Ce démonstrateur a besoin de JavaScript pour fonctionner. Le reste de la page reste lisible sans lui.
Plus aucun coup possible
Ce qu'il y a derrière
Ce qui suit s'adresse à qui veut savoir comment c'est fait. Le jeu se joue sans, et rien de ce qui est expliqué ici n'est nécessaire pour y jouer.
Les autres démonstrateurs de la section portent sur du raisonnement : le démineur refuse les grilles qui ne se déduisent pas, le sudoku classe ce qu'il a démontré. Celui-ci ne démontre rien de logique. Il porte sur la tenue à l'écran, qui est la partie du travail dont un client voit le résultat sans jamais en voir la cause.
Deux propriétés, deux quantités de travail
Déplacer un élément par transform et le déplacer par top et left donnent le même résultat à l'arrivée et deux coûts très différents en route. Une translation est appliquée après la mise en page : la position des autres éléments n'est pas recalculée, la surface n'est pas repeinte, et le travail se réduit à composer des couches déjà prêtes. Animer top ou left modifie au contraire des propriétés dont dépend la mise en page, donc le navigateur doit la refaire, à chaque image, pour l'arbre concerné.
Sur seize éléments et un plateau de 444 pixels, la différence peut rester invisible sur un poste de bureau récent. C'est précisément pourquoi la comparaison est dans la page plutôt que dans un tableau : la seule mesure qui vous concerne est celle de votre appareil, et l'écart se creuse là où il compte, sur un téléphone de milieu de gamme et sur une interface qui a plus de seize éléments à déplacer.
Pourquoi les deux voies sont comparables
Une comparaison n'a de valeur que si les deux termes ne diffèrent que par ce qu'on mesure. Le script n'écrit donc jamais de pixels : il pose sur chaque tuile deux propriétés personnalisées, une colonne et une ligne, valant zéro à trois. Tout le calcul de position vit dans la feuille de style, en un seul endroit, et les deux voies s'en servent. Elles parcourent la même distance, sur la même durée de 110 millisecondes, avec la même courbe. Ce qui change entre elles tient en une classe posée sur le plateau.
Un détail a décidé du reste : les distances sont en pixels et non en pourcentages. Un pourcentage passé à une translation se résout sur la boîte de l'élément déplacé, pas sur celle de son parent, alors qu'un pourcentage dans left se résout sur le parent. Les deux voies n'auraient pas parcouru la même distance, et la mesure aurait comparé deux animations différentes en croyant comparer deux propriétés.
Ce que le relevé dit et ce qu'il ne dit pas
La grandeur retenue est l'image la plus longue de chaque coup, et non la moyenne : une animation est jugée sur son pire moment, un joueur ne remarque pas les images réussies. La valeur publiée est la médiane des vingt derniers coups d'une voie, parce qu'un seul relevé ne tranche rien quand la dispersion est réelle, et qu'une médiane résiste à l'image parasite d'un autre onglet.
Deux réserves, parce qu'elles font partie du résultat. Firefox et Safari arrondissent l'horloge du navigateur à la milliseconde par défaut, par protection contre le pistage : sur un intervalle d'image d'une quinzaine de millisecondes, l'arrondi coûte quelques pour cent, et aucune valeur plus fine n'est affichée ici. Et la page mesure des intervalles entre images, ce qui est un symptôme, pas un diagnostic : l'outil qui dit où part le temps est le panneau des performances du navigateur, ouvert sur cette page pendant que vous basculez d'une voie à l'autre.
Le même geste, dans une application métier
Un plateau de tuiles est un prétexte lisible, mais le geste est celui d'une liste qui se réordonne, d'une carte déplacée d'une colonne à l'autre dans un tableau de suivi, d'un panneau qui s'ouvre sur le côté. Ce sont des animations d'interface courantes, et elles se codent des deux façons. La différence ne se voit pas sur la machine du développeur ; elle se voit sur le téléphone de la personne qui utilise l'outil huit heures par jour.
Le hasard est tiré à graine
L'apparition des tuiles est le seul aléa du jeu, et il passe par un générateur à graine, comme sur les trois démonstrateurs précédents. La graine et l'état du tirage sont conservés avec la partie, ce qui rend la reprise exacte plutôt qu'approximative et, surtout, rend un défaut rejouable : une partie qui produirait un comportement bizarre peut être rejouée coup pour coup au lieu d'être décrite de mémoire.
Un défaut a d'ailleurs été trouvé de cette façon avant la mise en ligne, par un harnais qui joue mille coups avec un DOM minimal et vérifie les règles du jeu à chaque coup. Le retour en arrière photographiait la grille après le calcul du coup, donc avec les valeurs des fusions déjà doublées aux anciennes positions : Annuler rendait une grille qui n'avait jamais existé. Rien de visible à la relecture, et rien qu'un joueur aurait signalé autrement que par un vague « c'est bizarre ».
Notre façon de travailler est détaillée dans notre approche du développement sur mesure, et les autres démonstrateurs sont regroupés dans la section jeux.
Une interface qui reste fluide sur l'appareil de vos utilisateurs
Tableaux de bord, outils métier, catalogues : nous concevons des plateformes sur mesure où la fluidité est un choix technique documenté, pas un espoir, à Toulouse et partout en France.
Parlons de votre projet