Discussion :

[aeled]

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

Sous chrome, si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[dukej]

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

Sous chrome, si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[aeled]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
    },

[Bovino]

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 :

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#

[aeled]

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

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 !

[Bovino]

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.

[NoSmoking]

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();

[aeled]

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

Plus performant ?

[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

[NoSmoking]

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.

[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....

[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 !!

[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

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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

[sekaijin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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