08.07.2016, 20:42
(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
Christian