... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Vorabversion 2.16 - Thread zum Melden von Problemen
#31
Bitte schreib doch die Schritte auf, die Dich dahin bringen - ich bekomme es hier mit der neuesten Vorabversion nicht mehr reproduziert.
--
Christian
Reply
#32
Also ich habe nun auch die Version vom 19.09 mal geladen (Die Windwos exe Version).
Dann öffne ich das Programm. Als Typ wähle ich Track, als Karte im Hintergrund habe ich nordrhein-westfalen.map. Zoomstufe stelle ich auf 18.
Dann klicke ich irgendwo auf einen Weg und wähle im Kontext "neu" => Erster Punkt.
Das wiederhole ich zügig mit weiteren Klicks entlang eines Weges mit abzweigungen. Eben hatte ich das Phänomen bereits beim dritten Punkt. Die Linie ging dann von Punkt 1 nach drei, von drei nach zwei und beim nächsten "neu" dann von zwei nach vier. In der Wegpunktliste sind alle Punkte in der richtigen Reihenfolge. Meist passiert es, wenn man relativ zügig die Punkte einfügt.
Reply
#33
Ich habe die nordrhein-westfalen.map auf Zoomstufe 18 gestellt und versucht, so zügig wie möglich im Kontextmenü "Neu" aufzurufen. Klappt.

Warst Du währenddessen Offline? Benutzt Du den "<Automatic>" Höhendienst?
--
Christian
Reply
#34
Nein weder Offline, noch Höhendienst. Seltsam. Kann es dann noch an Java liegen?
Reply
#35
(25.09.2015, 12:29)fboedecker Wrote: Nein weder Offline, noch Höhendienst. Seltsam.

Ich hatte die Vermutung, daß das ein Timingproblem ist: irgendetwas ist schneller oder langsamer als bei mir.

(25.09.2015, 12:29)fboedecker Wrote: Kann es dann noch an Java liegen?

Eigentlich nicht. Könntest Du vielleicht ein Video machen, während Du den Fehler bei Dir reproduzierst? Dann sehe ich vielleicht Details, die mir helfen, das Problem einzugrenzen.
--
Christian
Reply
#36
Es ist schon verhext, wenn im Hintergrund der Screenrecorder läuft, kann ich es nicht reproduzieren.
Dann habe ich mal getestet, langsamer zu klicken und dann kommt der Fehler auch nicht. Ich glaube, es liegt allein an meiner Umgebung. Steck keinen Aufwand darein, ich kann damit leben
Reply
#37
Hallo Christian,

(27.07.2015, 07:37)lundefugl Wrote:
(25.07.2015, 21:17)routeconverter Wrote: Jedes Mal?
Ja. Evtl. liegt das auch an meinem Monitor. Das ist ein 30"er und der RC läuft im Vollbildmodus.


(25.07.2015, 21:17)routeconverter Wrote: Dann schmeiß doch mal den Debugger an und schaue, was MapView#resize() und #resizeMap() so machen.

werde ich machen, sobald ich mal etwas Zeit und Ruhe habe. Muss dazu erst mein Dev-System mit Git reaktivieren. Kann daher noch etwas dauern.

mein Dev-System läuft ja wieder und ich bekomme das Problem mit der abbrechenden Linie auch im Debugger hin (was ja nicht immer selbstverständlich ist ;-).

Das Ergebnis ist, dass MapView#resize() und #resizeMap() beim Verschieben der Karte überhaupt nicht aufgerufen werden. Das wundert mich eigentlich auch nicht, da sich ja keine Größe ändert.
Kannst du mir irgendeinen anderen Punkt nennen, der beim verschieben der Karte aufgerufen werden sollte, so dass ich etwas habe, ab wo ich mich durchhangeln kann ?

Gruß
Thomas
Reply
#38
(04.07.2016, 18:46)lundefugl Wrote: Das Ergebnis ist, dass MapView#resize() und #resizeMap() beim Verschieben der Karte überhaupt nicht aufgerufen werden. Das wundert mich eigentlich auch nicht, da sich ja keine Größe ändert.

Das hätte ich auch nicht erwartet.

(04.07.2016, 18:46)lundefugl Wrote: Kannst du mir irgendeinen anderen Punkt nennen, der beim verschieben der Karte aufgerufen werden sollte, so dass ich etwas habe, ab wo ich mich durchhangeln kann ?

BrowserMapView.centerChanged() ist ein Start. Ich habe da etwas Aufwand in Java und JavaScript getrieben, dass es nicht ständig zu einem Repaint führt.
--
Christian
Reply
#39
Hallo Christian,

(04.07.2016, 21:08)routeconverter Wrote: BrowserMapView.centerChanged() ist ein Start. Ich habe da etwas Aufwand in Java und JavaScript getrieben, dass es nicht ständig zu einem Repaint führt.

wie es aussieht, passiert es, wenn man in einem großen (aber nicht dem größten !!) Zoomlevel schnell die Karte verschiebt.
Dann kann es passieren, dass "centerChanged" aufgerufen wird, während gerade eine Neuberechnung aus dem "positionListUpdater"-Thread läuft. Dadurch kollidieren wohl im PositionReducer der "reducePositions"- und "clear" -Aufruf.
Ab da setzt dann niemand mehr "haveToRepaintRouteImmediately" aus dem "centerChanged" auf true, weil man nicht mehr dahin kommt.
Allerdings hätte ich gesagt, dass das bereits true sein müsste, aber der "positionListUpdater"-Thread kommt sehr sehr lange nicht mehr dran und wenn es passiert, dann fällt er ins Continue, da scheinbar "haveToRepaintRouteImmediately" auf false steht.

Ich kann dir leider nicht erklären, warum das so ist.
Ich habe mal versuchsweise die beiden Funktionen "clear" und "reducePositions" per syncronized verriegelt. Danach konnte ich den Effekt nicht mehr reproduzieren. Ich weiss aber nicht, ob das evtl. nur am dadurch geänderten Timing liegt und der Fehler trotzdem noch da ist. In meinen Augen müsste es ja funktionieren.

Das mal als erste Analyse. Ich kann evtl. am Sonntag wieder etwas damit herumprobieren und debuggen.


Gruß
Thomas
Reply
#40
(06.07.2016, 19:52)lundefugl Wrote: wie es aussieht, passiert es, wenn man in einem großen (aber nicht dem größten !!) Zoomlevel schnell die Karte verschiebt.

Hallo Thomas,

vielen Dank fürs Testen und Debuggen. Ich bekomme so etwas nie hin - auch jetzt mit Deiner Beschreibung nicht.

(06.07.2016, 19:52)lundefugl Wrote: Dann kann es passieren, dass "centerChanged" aufgerufen wird, während gerade eine Neuberechnung aus dem "positionListUpdater"-Thread läuft. Dadurch kollidieren wohl im PositionReducer der "reducePositions"- und "clear" -Aufruf.

Eigentlich wird ja nur PositionReducer#clear() sowie 1 von 2 Aufrufen von PositionReducer#hasFilteredVisibleArea() mit dem notificationMutex Lock geschützt. Das sieht in der Tat nicht schlau aus.

(06.07.2016, 19:52)lundefugl Wrote: Ab da setzt dann niemand mehr "haveToRepaintRouteImmediately" aus dem "centerChanged" auf true, weil man nicht mehr dahin kommt.
Allerdings hätte ich gesagt, dass das bereits true sein müsste, aber der "positionListUpdater"-Thread kommt sehr sehr lange nicht mehr dran und wenn es passiert, dann fällt er ins Continue, da scheinbar "haveToRepaintRouteImmediately" auf false steht.

Wenn PositionReducer#clear() aufgerufen wird, liefert PositionReducer.hasFilteredVisibleArea() immer false, da visible = false. Und in #centerChanged() wird haveToRepaintRouteImmediately nicht auf true gesetzt

Könnte es das sein?

(06.07.2016, 19:52)lundefugl Wrote: Das mal als erste Analyse. Ich kann evtl. am Sonntag wieder etwas damit herumprobieren und debuggen.

Das wäre cool.
--
Christian
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)