Forums : Xul, Xbl, JS...

Hello,

En ce qui concerne la méthode hasNextSibling, j'ai eu un peu de mal à l'implémenter moi aussi, et j'ai aussi pu remarquer qu'elle était appelée très souvent. Du coup j'utilise un grand tableau dans ma vue qui garde en cache les nextSibling de tout les noeuds visibles pour éviter de les calculer à la volée. Après il ne reste plus qu'a le mettre à jour correctement ;)

Pour les méthodes beginUpdateBatch et endUpdateBatch elles sont effectivement très utiles, surtout dans ton cas ou tu ajoutes plusieurs centaines de lignes. Fait un appel à beginUpdateBatch avant de commencer l'ajout, et un à endUpdateBatch juste après, ça devrait pas mal améliorer les choses. En faisant ainsi l'arbre va bloquer les mises à jour entre les deux appels, du coup il ne fera qu'une grosse mise à jour à la fin au lieu de beaucoup de petites pendant.

Merci pour ta réponse Papy.

Pour une raison purement esthétique, je ne dessine plus les liens entre les éléments de l'arbre. Du coup, l'implémentation de "hasNextSibling" ne se résume plus qu'à un "return false;". Cette méthode n'est pas en cause dans le problème de performance constaté.

begin et endUpdateBatch pourraient en effet me servir à geler la mise à jour de l'arbre pendant son chargement depuis un fichier XML. Mais le chargement s'effectue assez rapidement.

C'est lorsqu'on consulte l'arbre et qu'on le fait défiler de haut en bas que la conso CPU de xulrunner grimpe et que l'affichage saccade. Sur un PC plus récent, c'est moins marqué, mais on le ressent de plus en plus avec le nombre d'entrée qui augmente...

J'ai court-circuité getCellText avec un "return '';" mais aucune amélioration...

Est-ce un problème d'implémentation d'une autre de mes méthodes ou est-ce le principe même de mon appli (un arbre perso qui prend tout l'écran) qui ne plait pas à gecko (moteur responsable de l'affichage si j'ai bien compris) ou à windows ou à mon ordi (processeur)?

Je n'ai pas l'expérience d'une application similaire compilée utilisant l'api windows (l'idéal pour une appli sous windows XP me semble-t-il, j'entend au niveau perfo) et je ne peut donc pas relativiser.

Si quelqu'un a cette expérience...

Bonjour, Je ne sais pas si cela a un rapport direct avec la problématique évoquée, mais j'ai résolu une lenteur d'affichage sur des peuplement d'arbres à peu près 10 fois plus volumineux que celui-ci en tout simplement passant l'arbre en collapsed="true" en début de traitement et en supprimant l'attribut collapsed en fin de traitement. Même chose quand je supprime une palanquée de lignes. Je pense que tous les traitements d'affichage et autres traitement connexes sont désactivés alors ...

bonjour

je n'ai pas bien compris pourquoi tu n'implementais pas hasNextSibiling. dans mon cas, je ne defini pas meme cette fonction dans le treeview, car je ne me sers pas de l'aspect hierarchique de l'arbre.

j'arrive a avoir des arbres de 20 cols sur 300 lignes dont le load est un peu long (en fait le traitement cote serveur) mais donc l'affichage est quazi instantane.

je ne connaissais pas start et end batch, donc je ne l'utilise pas encore..

pour faire part de mon experience, j'ai cette apres midi, fait un arbre de 27000 lignes en RDF avec dont-build-content, et le resultat s'affiche instantanément. Mais FF se freeze, jusqu'a la reception de toute les données. En effet pour avoir le resultat instantanément, j'ecrit coté server directement sur le OutputStream de l'echange http. J'utilise java coté serveur je sais pas si la mm chose est faisable en php (surement). L'avantage c'est que les lignes s'affiche avant que le RDF ne soit fini. Pour un nombre moins important de ligne, 2000 c'est instantané sans freeze, pour plus 8000 on voit un lag a peine perceptible. J'essayerais de faire une demo prochainement en ligne.

PS : tout ca fullRemote

• Heu ... je comprends pas bien : ça s'affiche instantanément et ça freeze jusqu'à la fin de la réception des données? C'est pas antinomique ça?
• J'imaginais que c'était possible en java, moi je fais tout en php ...
• à la louche combien de colonnes par ligne rapatries-tu ? Je vais générer quelques fichiers pour voir ce que ça donne et je mettrai ça en ligne.

Christophe Charron a écrit:

- Heu ... je comprends pas bien : ça s'affiche
instantanément et ça freeze jusqu'à la fin de la
réception des données? C'est pas antinomique ça?

Ben en fait comme j'ecris directement sur le output de la response (tjs en java), le resultat commence à s'afficher avant que mon traitement metier soit terminer. Néanmoins le traitement du flux coté client est tel que ca freeze qd mm, malgé le dont-build-content. Mais c'est la reception du flux qui met le tout a mal.

- J'imaginais que c'était possible en java, moi je
fais tout en php ...

Ben moi, je fais tout en java, mais ya pas de raison que ce soit pas possible en php

- à la louche combien de colonnes par ligne
rapatries-tu ? Je vais générer quelques fichiers
pour voir ce que ça donne et je mettrai ça en
ligne.

Ben à la louche à peu pres 2, et non arborescent. Mais un pote à testé avec 37000 ligne arborescente (je sais pas pr les colonnes) et il me dit 3 sec pour affichage et 8 secondes de freeze, ou un truc comme ca faudrait que je vois sont truc.

Apparement personne n'a constaté de problème de performance à l'utilisation (monter et descendre la vue d'arbre avec l'ascenseur par ex), mis à part au chargement mais ça peut se comprendre.

Je rapelle que je fait une appli XUL standalone, sans BD derrière. Tout se passe en local. J'utilise une vue d'arbre personnalisée.

J'instancie ma classe (si je puis dire) d'arbre vue perso que j'associe à l'objet d'interface XUL tree. Je peut construire ensuite une arborescence noeud par noeud à l'aide d'interfaces de saisie. Chaque ajout d'éléments dans l'arbre instancie un nouvel objet JavaScript qui est relié à la source de données qui au final constitue un arbre d'objets JavaScript hiérarchisé. La vue d'arbre tire ses infos à afficher de cette source de données. Tout marche excessivement bien.

Mais malheureusement, le fait de décrire des cercles au dessus de cette arbre (quelque chose d'anodin pourtant !?) suscite anormalement mon CPU (le processus xulrunner.exe atteind en 2 sec une conso proche de 100%).

Le problème peut venir, je pense, de deux choses :

  - très mauvaise implémentation de ma vue d'arbre ou oubli de désactiver une fonction de rafraichissement. 
  - le principe ou la logique métier (ma source de données) qui est très grande consommatrice de ressource CPU (derrière chaque ligne de l'arbre se trouve un objet JavaScript).

Dans tous les cas, merci pour vos témoignages

David

Simplification de la problématique :

comment se fait-il qu'au survol de la souris sur une ligne de mon arbre perso, une partie des méthodes de la vue d'arbre sont appellée (getCellText, getLevel, getParentIndex, ...) ?

Si oui, comment puis-je désactiver (et du coup re activer) cette mise à jour continuelle des infos contenues dans l'arbre lorsque la souris le survole?

A tout hasard : removeEventListener ? puis addEventListener ?

Bonjour,

je pense que getCellText est appelée quand la souris se déplace de ligne en ligne ou colonne en colonne car l'arbre doit récupérer la valeur pour éventuellement construire le tooltip qui s'affiche quand la colonne n'est pas assez large pour afficher toute la valeur. Ce n'est peut-être pas la seule cause, mais je pense que c'est un début.

D'après mes tests, getCellText est appelée un paquet de fois (en fait, dès que la souris bouge de 1px).

pour les autres fonctions, je n'ai pas encore testé.

pour désactiver la chose, je n'ai pas vraiment de solution, et je ne suis pas persuadé que ce soit souhaitable dans le fond (a priori si c'est appelé, il doit y avoir une raison)

Julien

Julien, ne penses-tu pas qu'il y a un niveau intermédiaire entre les données sources et les données affichées par l'arbre? (une sorte de cache qu'il est possible de mettre à jour suite à une modif d'une données). A quoi sert alors les méthodes invalidate*() de l'objet nsITreeBoxObject ???

Je trouve dommage que l'abre interroge trop souvent les données sources, alors qu'elles sont déjà affichée. Je le conçoit très bien au premier affichage, mais pas après.

As-tu constaté, avec une qté de donnée d'environ 100 lignes, un quelconque ralentissement et une conso CPU du processus xulrunner.exe élevée?

C'est peut-être à nous d'implémenter un cache, mais cela va-til améliorer les performances?

POur répondre à Christophe, je pense que cela pourrait être une solution de désacter ponstuellement l'évenement mouseover sur l'arbre, mais je voudrais avant tout savoir si un mécanisme natif existe.

Comment se fait-il qu'avec des données issuent de RDF, ces ralentissement ne sont pas constatés? Comment est implémenté et fonctionne la vue d'arbre avec les RDF? Fait-elle autant d'appels au passage de la souris ???

Pour ta réponse oui c'est à nous d'implémenter un cache, l'interface nsITreeView et le dernier composant entre l'affichage et les données (enfin je crois :P)

Ce qu'il faut surtout éviter, c'est d'avoir des traitements à effectuer dans les méthodes getCellText/getCellValue, et encore pire pour le hasNextSibling et les autres méthodes qui gèrent le côté hiérarchie (celles ci sont appelées beaucoup plus souvent que les précédentes)

Pour ma part, mes vue contiennent un tableau avec les éléments à afficher, les appels se résument donc à un accès tableau et un accès propriété la plupart du temps, du style :

 getCellText: function(rowIdx, col) {
   return this.elements[rowIdx].text;
 }

J'ai quand même quelques tests en plus, entre autre pour vérifier l'index et éviter un out of bound, mais vraiment peu de traitement.

Pour gérer d'autres attributs plus problématiques, comme le nextSibling, je l'enregistre en tant que propriété de mes éléments, ce qui résume encore une fois l'appel à quelques accès. En revanche il faut tenir ça à jour, ce qui demande de gros traitements ! Je le fais donc à la construction de ma vue et lorsque qu'un item est ouvert/fermé.

En ce qui concerne les vues RDF, elles ont une instance de TreeView spécifique, c'est donc fort possible qu'elles implémentent un cache ou quelque chose du style pour éviter trop d'accès à la source de donnée (ou alors les accès à cette source sont très rapides)

Enfin en résumant, pour avoir un maximum de performances avec les TreeView, pas de traitements dans l'appel des méthodes qui ne font que renvoyer une donnée.

Bonjour,

Papy, tu as raison, il faut effectuer un minimum de traitements dans l'appel des méthodes qui ne font que renvoyer une donnée (getCellText()/getCellValue()). D'où l'utilisation d'un cache fait maison. L'amélioration est visible même si ça ne se rapproche pas encore de l'arbre avec datasource RDF. Je considère le sujet comme étant résolu.

Je tiens tout de même à préciser que la méthode hasNextSibling() n'influe pas (à moins d'avoir coder avec les pieds) sur les performances de l'arbre, chez moi en tous cas. Je l'ai "bypassée" tout simplement et aucune amélioration ressentie.

getParentIndex() ne me semble pas être en cause non plus (à vérifier). J'ai essayé l'implémentation où le calcul était effectué "à la volée" pour finir par la création d'un attribut parentIndex directement retourné par la fonction, attribut mis à jour suite à l'appel de la méthode toggleOpenState(). Aucune amélioration ressentie. Peut être que l'amélioration a été noyée dans la contre performance (vous me suivez ?!)...

Je tenais à remercier toutes les personnes qui m'ont aider sur ce sujet.

David