C'est long, mais j'ai le même, mais ça se provoque de manière
aléatoire et sauvegarder son travail devient ridiculement compliqué.
Pour moi ça apparaît avec le plugin cadastre.
Le 11 oct. 2014 16:11, "Philippe Verdy" <verd...@wanadoo.fr
<mailto:verd...@wanadoo.fr>> a écrit :
De plus en plus souvent je constate des pertes inopinées de
contrôle du clavier ou de la souris dans JOSM; rendant
l'interface inopérante.
Par exemple :
- les touches + et - (qu'on les tape sur le pavé numérique ou le
clavier alpha) du zoom cessent de répondre (dans ce cas aussi
cela ne marche plus non plus avec le menu ni un raccourci posé
sur une icone de la barre d'icones (c'est le cas le plus
fréquent) Et pourtant le zoom sur la sélection fonctionne encore
et le zoom avec + ou - dans le dialogue de téléchargement d'une
zone fonctionne encore.
- quand on ouvre un dialogue; le focus sur le champ de saisie ne
fonctionne pas et impossible de taper un texte dedans parfois
aussi la sélection à la souris d'un morceau du texte ne marche
plus (en revanche les autres boutons, y compris le triangle du
sélecteur d'une combobox) fonctionne encore. La fermeture du
dialogue et sa réouverture suffit parfois à rétablir la fonction;
mais pas toujours...
- la suppression et le remise d'une icone de raccourci sur la
barre d'icone fonctionne, mais le bouton ne produit toujours rien
quand on clique dessus.
Il semble qu'il y a un bogue dans la bibliothèque qui gère les
"bindings" attachant des événements clavier ou souris à un
gestionnaire d'événement; comme si le gestionnaire avait été
perdu par perte de référence (allocation en "weak pointer" et
effet du garbage collector, ou mauvaise synchronisation de
l'ordre des événements en cas de modification dynamique de la
liste des bindings (modification non atomique, comme si la
suppression de référence au gestionnaire d'événement dans une
liste de gestionnaires a eu lieu *avant* l'insertion de ce même
gestionnaire dans une autreliste pour un autre élément
d'interface utilisateur).
Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses
bibliothéques de construction d'UI; ou si la modification
dyna,ique de l'interface a oublié de mettre un verrou entre
plusieurs threads faisant des modifications concurrentes de l'UI
(par exemple un thread s'occupant de la construction d'un nouveau
dialogue tandis qu'un autre thread s'occupe encore de celui de la
fenêtre principale; ou bien l'événement à réassigner est encore
en cours de traitement par le thread principal qui gère la liste
ordonnée des événements UI et synchronise les rafraichissements
écran).
Seule parade : sauver les modifs en cours dans un fichier local,
fermer JOSM et le relancer pour charger le fichier à nouveau.
Mais à je suis tombé sur un cas où c'était la fonction
sauvegarder qui ne fonctionnait plus aussi bien au clavier
(CTRL+S), qu'à la souris en cliquant l'icone de la barre d'icones
ou par le menu fichier.
C'est de plus en plus gênant car l'anomalie se reproduit de plus
en plus souvent et aboutit à des pertes de modifs en cours (très
gênant quand on a eu besoin de charger beaucoup de données et
vérifier des jeux compliqués de relations interdépendantes, comme
la vérification des cours d'eau, des lignes de bus, vérifier le
routage, refermer les trous dans des relations (par exemple par
ceux qui remplacent sans faire attention des routes ou
transforment un carrefour simple en rond-point tracé n'importe
comment et ne tenant pas compte de l'existant qui s'y connecte
(ceux-là ne connaissent pas CTRL+ALT+D dans JOSM et sont
totalement perdus dans iD qui presque tout le temps fait
n'importe quoi et est très peu utiisable pour autre chose que
d'ajouter des tags ou faire un tracé sommaire ou ajouter un POI
ou affiner le tracé existant; mais pas pour transformer des
objets: d'ailleurs les mêmes beaucoup trop souvent ne
s'embarassent pas de transformer l'existant, ils retracent et
suppri,ent tout ce qui les gêne et ne fait doublon qu'avec leur
nouveau tracé, ou qui passe une route simple bidirectionnelle en
routes à deux voies unidirectionnelles séparées et oublient de
router la ligne de bus en sens inverse qui passait par la
première voie laissée mais devenue sens unique; créant des routes
impossibles).
D'une façon générale JOSM a de plus en plus souvent des soucis de
rafraichissement partiel de l'écran et semble souffrir de bogue
de synchronisation entre ses threads de plus en plus nombreux
(chez moi la moindre session prend maintenant plus de 400 threads
parallèles, alors que j'tilise un jeu très réduit de plugins
parmi les plus "stables".
Je détecte cette anomalie depuis début août, mais cela s'aggrave
maintenant
Note: je suis toujours à jour des versions, je lance JOSM par
JNLP sur la dernière version en release stable. Et ceci quelque
soit le PC utilisé (sous Windows 7 ou 8.1); avec la dernière
versions stable de Java (en version "Hotspot Server VM" 64 bits
en Java 6 ou 7; pas la version 32 bits qui limite trop la mémoire
maxi utilisée alors que j'ai beaucoup de mémoire, et sollicite
énormément le garbage collector ce qui fait des pauses beaucoup
trop souvent, en 64 bits mes VM Java montent sans problème à 2
gigas, et le garbage collector utilise des threads en
arrière-plan qui ne font jamais aucune pause; et la version
serveur 64 bits sait utiliser les 8 coeurs CPU à la demande et a
un bien meilleur scheduler de threads et consomme beaucoup moins
de CPU pour la VM toute entière, ce qui laisse le reste de l'OS
travailler correctement).
Constatez-vous le même problème ? avez-vous une explication ou un
moyen d'éviter ça ? (paramètre de VM Java par exemple, ou package
de remplacement d'une librairie système ou quelquchose qui
n'était pas recommandé ni supporté officiellement par l'API mais
ne fonctionne plus de la même façon sur les versions récentes de
Java).
Je soupçonne une anomalie de Swing, ou une mauvaise utilisation
(car Swing lui-même n'est pas synchronisé dans la plupart de ses
APIs, pour des questions de performance et demande que soit on
l'utilise uniquement dans le thread principal, soit qu'on fasse
des synchrox explicites sur un verrou applicatif (et notamment
dans le constructeur ou le finaliseur d'une classe ou quand on
utilise des "weak pointers" pour des objets de type "cache"
sensés être libérables à tout instant et reconstructibles à la
demande en utilisant une méthode de factory à chaque fois et en
rendant privés les constructeurs).
(Note : je n'utilise plus Swing dans mes applis Java : trop lent;
pas assez souple; conception inutilement compliquée; mauvaise
adaptation au contenu; rendu du texte et méthodes de saisie
exécrables, je préfère les bibliothèques développées initialement
pour l'UI d'Eclipse, mais utilisables depuis longtemps séparément
car elles sont plus réactives, mieux écrites, et gèrent mieux les
accélérations matérielles disponibles, Swing est également un
gouffre en ressource mémoire et construit trop d'objets très
temporaires, il ne gère pas leur cycle de vie correctement et
sollicite trop le garbage collector: Swing est préhistorique et
fonctionne très mal avec les UI qui changent dynamiquement selon
le contenu, il permet juste de faire des boîtes d'alerte avec 3
boutons et un texte statique)
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
