[Tsp-devel] RE: Amélioration importante dans JSynoptic

[DUFRENNE, Yves]

C'est que du bonheur.
Il y a une version officielle sur le site (ou prévue dans un temps certain),
ou je fais un update -A et un commit pirate sur TSP ?
Y++

> -----Original Message-----
> From: BRODU, Nicolas 
> Sent: Thursday, March 11, 2004 2:56 PM
> To: address@hidden; DUFRENNE, Yves; GONZALEZ,
> Wilfrid
> Cc: CAZENAVE, Claude
> Subject: Amélioration importante dans JSynoptic
> 
> 
> Bonjour,
> 
> Je viens de terminer une amélioration importante dans le système de 
> notifications d'évènements de JSynoptic.
> Pour résumer, ceci permet d'attendre à un niveau (Shape) que 
> toute les 
> notifications qui proviennent d'un évènement unique soient accomlies 
> (ex: mise à jour d'une collection de données complète par le 
> réseau). Je 
> passe les détails d'implémentation (référence counting, remontée de 
> l'enregistrement à un niveau unique pour éviter doublons, etc...). Le 
> truc qui a tout débloqué était de se rendre compte que ce n'est pas 
> forcément l'objet sur lequel on enregistre un listener de fin 
> d'évènement qui va par la suite activer ces listeners, et 
> d'autant plus 
> pour éviter les doubles appels en fin d'évènement. Voir l'interface 
> EndNotificationListener pour plus de détails.
> 
> D'où un algorithme optimisé. Qui plus est l'ancienne 
> implémentation est 
> source et binaire-compatible, même si je recommande fortement 
> de passer 
> à la nouvelle façon de faire dans la majeure partie des cas (voir 
> EndNotificationListener pour plus de détails).
> 
> Exemple pour une shape qui écoute sur 2 données d'une 
> collection dynamique:
> 
> Avant:
> évènement extérieur  =>  mise à jour collection
> source 1 notifie shape que son index a changé => shape notifie ses 
> listeners qu'elle est changée le cas échéant
> source 1 notifie shape que sa plage de valeur a changée => 
> shape notifie 
> ses listeners qu'elle est changée le cas échéant
> ...
> source 2 notifie shape que son index a changé => shape notifie ses 
> listeners qu'elle est changée le cas échéant
> source 2 notifie shape que sa plage de valeur a changée => 
> shape notifie 
> ses listeners qu'elle est changée le cas échéant
> ...
> timer dans AbstractShape collecte les évènements de notification des 
> shapes et les fusionne à 100ms, ce qui arrive tout le temps
> 
> Maintenant:
> évènement extérieur  =>  mise à jour collection
> source 1 notifie shape que son index a changé => shape regarde si 
> affectée et prend note le cas échéant
> source 1 notifie shape que sa plage de valeur a changée => 
> shape regarde 
> si affectée et prend note le cas échéant
> ...
> source 2 notifie shape que son index a changé => shape regarde si 
> affectée et prend note le cas échéant
> source 2 notifie shape que sa plage de valeur a changée => 
> shape regarde 
> si affectée et prend note le cas échéant
> ...
> collection a fini ses mise à jour => shape prévient ses 
> listener si elle 
> a pris note de le faire
> timer dans AbstractShape collecte les évènements de notification des 
> shapes et les fusionne à 100ms, ce qui arrive beaucoup moins souvent.
> 
> L'ancien fonctionnement avait 3 problèmes:
> - La shape notifiait ses listeners à raison de N * nsources à chaque 
> update réseau, où N = 2 à 4 selon les fois pour un plot 
> standard. Soit 
> pour un plot avec 3 données d'affichées + le temps et dans le 
> meilleur 
> des cas 2 *4 = 8 remontées vers JFreeChart (même si un seul dessin 
> effectif tous les 100ms, les paramètres des plots étaient quand à eux 
> rafraichis 8 fois!)
> - L'ordre d'arrivée des évènements était trop imprévisible 
> pour pouvoir 
> faire des tests propres. Par exemple, si une couleur de fond d'une 
> cellule de texte de la source 1 dépend en fait de la source 2, il y 
> avait 4 rafraichissements successifs, 2 pour la source 1, et 
> 2 pour la 
> source 2. Dans ce cas ça ne gêne pas trop, au pire il y avait 
> un flicker 
> si les rafraichissements étaient effectuées sur 2 intervalles 
> de 100ms 
> distincts. Mais nous avions vu avec Wilfrid un bug bizarre sur 
> l'automate cellulaire, qui lui dépends de l'ordre d'arrivée dans 
> certains cas. Ceci est encore pire pour les matrices de 
> rotation en 3D...
> - De façon détournée certains listeners pouvaient être enregistrés en 
> double (je passe les détails, mais c'était un effet de bord 
> inévitable).
> 
> Le nouveau fonctionnement permet de les résoudre
> - Il n'y a plus qu'un seul rafraichissement vers JFreeChart 
> dans le cas 
> ci-dessus => gain de perf non négligeable.
> - Il n'y a plus de doublons, chaque listener n'est notifié 
> qu'une fois 
> par évènement même s'il est enregistré en double (effet de bord 
> identique, conséquences différentes).
> 
> Donc, beaucoup de bugs bizzare et peu reproductibles se trouvent 
> corrigés au passage, en plus d'une amélioration globale des 
> performances.
> 
> Happy Hacking!
> Nicolas
>

important_notice.txt
Description: Text document