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.