Chrome javascript innerHTML lenteurs

Version imprimable

26/01/2011, 10h53
aeled

Chrome javascript innerHTML lenteurs

Je viens d'identifier un soucis sur une appli que je développe.

Sous chrome, si je fais :

Code:

cell.innerHTML = "bb"

Ou cell est un td dans une boucle. Ok, pas de problèmes, j'affiche tout ça à l'écran.

En revanche si à la place d'une string simple, j'ai du code html avec balises, l'affichage se fait, mais tout chrome se met à lagger méchant !

Est-ce que c'est un bug connu ?

Pas de problème sous firefox / IE
26/01/2011, 11h57
dukej

Citation:

Envoyé par aeled

Je viens d'identifier un soucis sur une appli que je développe.

Sous chrome, si je fais :

Code:

cell.innerHTML = "bb"

Ou cell est un td dans une boucle. Ok, pas de problèmes, j'affiche tout ça à l'écran.

En revanche si à la place d'une string simple, j'ai du code html avec balises, l'affichage se fait, mais tout chrome se met à lagger méchant !

Est-ce que c'est un bug connu ?

Pas de problème sous firefox / IE

Le code de la boucle svp

Oulah. La boucle passe par plusieurs callbacks différents, du code c# etc...

La méthode complète qui ajoute le flux html à la page :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
appendData: function (result, context) {        
        pId = $get("docTable");       
        if (pId.rows.length > 0) {
            while ($.inArray(myDocument.list_sequences_affichees[0], myDocument.list_sequences) == -1) {
                pId.deleteRow(0);
                myDocument.list_sequences_affichees.splice(0, 1);
            }
        }
        var row = pId.insertRow(pId.rows.length);
        var cell = row.insertCell(0);
        cell.id = context;
        cell.innerHTML = result;
        myDocument.lock = 0;
    },

26/01/2011, 12h42
Bovino

Citation:

Est-ce que c'est un bug connu ?

Bug, oui et non... connu, oui !

En gros, le principe est que les tables sont les éléments les plus lourds à générer pour un navigateur (calcul des dimensions de chaque élément qui le compose).
Or dans ta boucle, le navigateur doit recalculer toutes les dimensions à chaque itération et à chaque insertion, donc plus ta table est grande, plus ça rame !

Une solution serait éventuellement de passer par un affichage sans table :)

Autre détail :

Citation:

La boucle passe par plusieurs callbacks différents, du code c# etc...

Non, il y a peu de chance que ta boucle JavaScript utilise du code C# :aie:
26/01/2011, 12h47
aeled

Citation:

Envoyé par Bovino

Non, il y a peu de chance que ta boucle JavaScript utilise du code C# :aie:

Avec un callback asynchrone si ;) Marche très bien :)

Enfin pour être précis ce n'est pas la boucle qui appelle les callbacks car ça non ce n'est pas possible mais j'ai bien du JS qui appelle du C#

Ce qui est étrange c'est que ça devrait faire lagger tous les navigateurs et non pas seulement celui qui habituellement est le plus réactif !
26/01/2011, 13h10
Bovino

Citation:

Envoyé par aeled

Ce qui est étrange c'est que ça devrait faire lagger tous les navigateurs et non pas seulement celui qui habituellement est le plus réactif !

Là encore, oui et non...
Les navigateurs possèdent un moteur JavaScript et un moteur de rendu. Donc si le moteur JavaScript est performant, les scripts s'exécuteront bien entendu plus vite, mais si d'un autre coté, le moteur de rendu est mauvais (par exemple pour l'affichage des tables), ça ramera quand même. Dans le même temps, un navigateur moins performant niveau JavaScript pourra sembler plus performant si son moteur de rendu des tables est meilleur.
26/01/2011, 15h37
NoSmoking

Citation:

Envoyé par aeled

En revanche si à la place d'une string simple, j'ai du code html avec balises, l'affichage se fait, mais tout chrome se met à lagger méchant !

cela risque fort également de dépendre de la construction suite à l'insertion des balises et de leur type.

Peut être l'occasion de voir du coté de createDocumentFragment();
26/01/2011, 16h48
aeled

Citation:

Envoyé par NoSmoking

Peut être l'occasion de voir du coté de createDocumentFragment();

Plus performant ?
26/01/2011, 17h55
le_chomeur

as tu essayé en remplissant la cellule de ton tableau en passant par le dom ?

tu créer une span ( dom )

maspan.innerHTML = toncontenu;
matd.appendChild(maspan);

cdt,

chomy
26/01/2011, 18h49
NoSmoking

Citation:

Envoyé par aeled

Plus performant ?

en théorie oui d'après ce que j'ai pu lire à droite ou à gauche comme DOM DocumentFragments par exemple.

En pratique cela dépend de ce que l'on manipule et dans le cas de TABLE, élément lourd, comme la signalé Bovino, les essais que je viens de faire montre que le gain est infime.

On notera toutefois que Chrome sans être en tête est loin devant IE et FF mais derrière Opéra et Safari.

La méthode insertRow et insertCell ne sont pas franchement au top question vitesse.

il reste quand même un point à vérifier, c'est la conformité de ce que tu ajoutes, les navigateurs n'étant pas tous égaux devant la réparation des erreurs.
27/01/2011, 13h30
aeled

Bon, j'ai vu que le contenu qui me pose des problèmes de ralentissement de chrome comporte une montagne de div imbriqués. Ca s'explique. J'ai plus qu'à voir avec les gens qui s'occupent de la xsl qui génère ce contenu pour qu'ils sortent un truc propre. C'est pas gagné ça....:mouarf:
27/01/2011, 13h52
aeled

J'ai continué à investiguer en me basant juste sur la partie html / css / js

Le flux qui pose problème est inclus dans un bloc <div> avec un overflow auto, et je pense que ça joue beaucoup !!
05/02/2011, 13h32
sekaijin

oui l'utilisation de fragment tout comme l'utilisation d'élément DOM à la place des innerHTML
ne passent pas par le moteur de rendu
mais accèdent directement au DOM

donc dans les navigateur moderne c'est bien plus efficace.

par contre pour les ancien c'est plus partagé

quoi qu'il arrive on n'échappe pas au calcul des positions et dimensions

A+JYT
05/02/2011, 22h28
dukej
Tu devrais directement gérérer TOUT ton tableau en HTML dans une string.
La technique c'est que que chaque morceau de ta string tu le met dans un tableau :
Code:

1 2 3 4 5 6 var myStr = [] for (var i=0; malistedebidules.length; i++) { myStr.push(recuperelebordelenstrde(malistedebidules[i])); } monDivQuiContientLeTableau.innerHTML = myStr.join('');
Et voila tu as généré ton tableau et ton navigateur n'a pas laggué.

Ce qu'il faut savoir dans tout ça c'est que à chaque fois que tu fais un appel au dom ou à un innerHTML, cela entraine une demande de rafrachissement coté navigateur, et du coup comme tu en fais une grosse quantité dans une boucle, tu ralentis ton navigateur.
La technique que je t'ai montré consiste à n'appeler le rafraichissement de la page qu'UNE SEUL FOIS :)
11/02/2011, 13h08
aeled

Le réel problème que je rencontrais est le suivant :

http://bugs.jqueryui.com/ticket/6767

Mais tous les autres points sont tout à fait exacts ;)
11/02/2011, 19h09
sekaijin
Citation:
Envoyé par dukej

Tu devrais directement gérérer TOUT ton tableau en HTML dans une string.
La technique c'est que que chaque morceau de ta string tu le met dans un tableau :

Code:

1 2 3 4 5 6 var myStr = [] for (var i=0; malistedebidules.length; i++) { myStr.push(recuperelebordelenstrde(malistedebidules[i])); } monDivQuiContientLeTableau.innerHTML = myStr.join('');

Et voila tu as généré ton tableau et ton navigateur n'a pas laggué.

Ce qu'il faut savoir dans tout ça c'est que à chaque fois que tu fais un appel au dom ou à un innerHTML, cela entraine une demande de rafrachissement coté navigateur, et du coup comme tu en fais une grosse quantité dans une boucle, tu ralentis ton navigateur.
La technique que je t'ai montré consiste à n'appeler le rafraichissement de la page qu'UNE SEUL FOIS :)
C'est aussi vrai en utilisant le dom
tu fais tes créations d'élément que tu agence entre eux en fixant tous les attributs et les css dont tu as besoin
et tu ne fait l'insertion finale dans le dom de ta page qu'en dernier

ainsi le dom travail sur le dimensionnement de tes éléments sans demander de rafraichissement. et lorsque tu fais l'insertion dans la page il sait quelle taille il doit réserver et ne fait qu'un seul rafraichissement.

A+JYT