Discussion :

[floflo.hp]

Bonjour à toutes et à tous,

Comme évoqué dans l'intitulé, je viens vers vous non pas pour un problème technique mais plutôt pour recueillir votre avis sur une possible optimisation entre JS et l'actualisation d'affichage d'éléments (HTML/CSS).


Prenons un exemple :

Soit une grille de taille 100 par 200 où chaque cellules contient une couleur.
Cette grille pourrait être affichée en HTML/CSS via une <table> (et les balises qui en découlent tel que <tr> ou encore<td>), dans chaque cellule de cette table on appliquerait le style, le background-color par exemple, représentant notre grille de départ présent dans notre script JS sous forme de tableau classique (Array).

Imaginons à présent une fonction modifiant zéro, une ou plusieurs cellule(s), on entend par là "modifier sa couleur". Cette fonction peut être un automate cellulaire par exemple.
Une telle fonction peut donc, dans notre cas, modifier de 0 à 20'000 cellules.

La problématique pour obtenir la meilleure optimisation (de temps) étant :

Doit-on mettre à jour (modification du style) une à une chaque cellule même si sa couleur est inchangée
ou bien
Doit-on mémoriser les cellules ayant subi des changements puis mettre uniquement ces dernières à jour ?

Autrement dit, en reprenant notre exemple de grille, imaginons que notre fonction modifie réellement la couleur de 1'000 de nos 20'000 cellules. Est-il plus rentable de (re)modifier chaque cellule avec potentiellement une même couleur que la précédente (le cas pour 19'000 de nos cellules) ou bien serait-il plus rentable de mémoriser ces 1'000 cellules, dans une liste temporaire par exemple, pour ne modifier qu'elles. De même, quant est-il si l'on modifie réellement 19'000 de nos 20'000 cellules ?

Dans l'idée, d'un côte on applique systématiquement une modification visuelle (même inutile) de l'autre côté on nécessite de créer une liste temporaire, de vérifier s'il y a bien changement d'état/de couleur pour ajouter la cellule dans la liste des "modifiées", puis à la fin on re-parcourt cette liste de "modifiées" pour appliquer une modification visuelle.

[headmax]

Pour être honnête, je vois pas l'intérêt de mettre 20 000 cellules dans une page sachant que la pagination sert pour éviter cela "page trop lourde a charger". Si c'est une contrainte niveau exécutif alors ils feront chemin en arrière après quelques utilisation.

Doit-on mémoriser les cellules ayant subi des changements puis mettre uniquement ces dernières à jour ?

si ça impacte qu'une dizaine oui sinon il est parfois plus rapide de régénérer tout le tableau que de cibler avec variables temporaires les cellules modifiées.

[floflo.hp]

Merci pour cette rapide réponse !

Ce n'est pas tant le fait de mettre des cellules dans une page qui importe, ici j'ai parlé d'une grille de 100 par 200 mais plutôt que de parler de <table> nous pourrions parler d'image ou de dessin (Canvas JS ?) si tu préfères, ce qui est, sauf erreur de ma part, tout à fait acceptable.
Après une petite recherche, j'ai pu trouver que la résolution moyenne (enfin la plus utilisée) des écrans semble être de 1366x768 (suivi de 1920x1080), pour notre exemple, en adaptant l'image à l'écran et sa rotation (portrait/paysage), on aurait des cellules de 6px de largeur, autant dire une image pas très haute qualité en plein écran. Bref, je m'écarte un peu, ce que je voulais dire c'est que 20'000 cellules ne semble pas être bien dramatique, sauf erreur de ma part.

[headmax]

Si tu n'a pas de perte de performance, pourquoi pas, si les events js sont pas trop gourmands en CPU, si tout est bien optimisé, tu pourrais aussi implémenter du cache pour soulager le server selon la cible (backoffice privé pas nécessaire si il y a édition alors oubli, grand public plus que nécessaire) ... etc

[Watilin]

J’ai l’intuition que dessiner des rectangles dans un canevas sera plus performant que d’afficher une <table>… Mais c’est juste une intuition, il faudrait tester intensivement pour confirmer. Selon moi, le rendu d’une table est un calcul lourd, même si des années de mauvaises pratiques (tableaux imbriqués, contenus complexes, etc) ont forcé les développeurs de navigateurs à bien optimiser cette opération.

table-layout: fixed peut aider.

Qu’on choisisse canevas ou table, le problème de la mise à jour est le même : doit-on tout remplacer, ou réafficher seulement les modifications locales ? Si on peut connaître à moindre coût le nombre de cellules modifiées, personnellement je partirais sur une valeur arbitraire, disons 10 000 pour couper la poire en deux ; au-dessus de cette valeur, on remplace tout, en-dessous on fait seulement des mises à jour locales.

Dans le cas du canevas, il pourrait être intéressant de connaître la « proximité » des modifications (voisinage en x ou y) pour regrouper les modifications par zones géométriques. Mais peut-être que le calcul de proximité serait coûteux, je n’en sais rien. Encore une fois, il faut faire des tests.