Performance des TileFetchers

[lootwitch]

Ich glaub das man die Perfomence beim TileFetcher und dem angebundenen MapView steigern kann ... die Tiles laden nicht asynchron Mir ist auch aufgefallen das ich die Tiles zwischenlagern muss gepaart mit ihren x und y coordinaten ... damit gibt es zwei chaches da bei den verwendetetn sckalierungs methoden kopien angefertigt werden.

[lootwitch]

hab bissel verbessert ... eine sache noch und zwar du übergibst zuerst die "lade bilder" dann die echten .. die werden in der mapview dann geschrieben ... blöderweise werden aber die lade bilder immer! gezeichnet und dann die echten tiles überschrieben ... its vlt nur ne kleinigkeit aber könnte bissel performence ausmachen(doppeltes bildzeichen alle 30ms)

[floscher]

Ich schicke nur eine Default-Kachel, wenn die angeforderte Kachel in dem Moment noch nicht im Cache ist, d.h. wenn sie erst noch heruntergeladen werden muss. Das "doppelte" Zeichnen ist doch notwendig, da Du doch nur Kacheln anforderst, wenn sich die Karte bewegt (pan oder zoom), oder liege ich da falsch?

Soll heißen: Karte bewegt sich => Alle Kacheln müssen neu angefordert werden, da sich immer alle Kacheln gleichzeitig bewegen => TileFetcher schickt die Kachel aus dem Cache, oder die Default-Kachel und (sobald geladen) die richtige hinterher

[floscher]

die Tiles laden nicht asynchron

Woran machst Du das fest? Ich bin der Ansicht, dass sie sehr wohl asynchron laden (2-3 Threads)

Mir ist auch aufgefallen das ich die Tiles zwischenlagern muss gepaart mit ihren x und y coordinaten

Warum? Kannst Du sie nicht einfach jedes Mal beim TileFetcher anfordern?

[lootwitch]

^^ zum ersten nunja im Grunde ist das nicht erforderlich hoffe ich jedenfalls...^^ nunja die MapView hat e Liste mit allen Tiles die gezeichnet werden sollen... blöderweise wird beimrequesten praktisch doppelete BilderMenge in diese Liste geschrieben .. die default Kacheln und die echten ... die Frage ist kann man die default raushauen wenn die echten Teiles kommen oder kann man das anderes lösen? ... vlt ist es schneller wenn ich anfangs alle default kacheln als ganzes zeichne .. dann wird die schleife kleiner ...

zum zeiten Kommentar die Teiles laden von links nach rechts ... ^^ aber es kann sein das ich das einfach nicht ganz blicke

zum zweiten Teil ja ich muss die tiles zwischenlagern da der Bildschrim (alle paar milisekunden) refreshed wird ...beim refreshen werden die Tiles nicht neu angefordert sondern alle bisher gelieferten Referenzen geueichnet.

[floscher]

die Teiles laden von links nach rechts ... ^^

Aber in zwei bis drei Threads (ich habe mehr ausprobiert, das wurde dann aber zu träge, siehe #199). Vor allem bei einer langsamen Internetverbindung sieht man dann, dass nicht immer strikt von oben links nach unten rechts spaltenweise heruntergeladen wird, sondern dass es auch Ausnahmen von dieser Regel gibt.

die Frage ist kann man die default raushauen wenn die echten Teiles kommen oder kann man das anderes lösen?

Zwei Möglichkeiten:

• receiveTiles bekommt einen zusätzlichen Parameter (boolean default). Dann speicherst Du die Kachel nur bei false in deine Liste, die dann nur alle Nicht-Default-kacheln erhält
• Du machst es so wie der TileFetcher-interne Cache: Der Speicher in einer Art HashMap, die die Attribute (x, y, lod, mapstyle) auf die Kachel abbildet. So kommen keine Default-kacheln in die HashMap

ja ich muss die tiles zwischenlagern da der Bildschrim (alle paar milisekunden) refreshed wird ...

Der TileFetcher antwortet in unter 10ms, sobald alle Tiles im Cache sind. Sonst sind es etwa 30ms. Sollte das zu langsam sein, könnte ich Dir auch eine Methode im TileFetcher zur Verfügung stellen zum direkten/synchronen Zugriff auf den Cache (etwa "public static Bitmap requestTile(int x, int y, int lod)"), dann brauchst Du den zweiten Cache nicht. Das war ja eigentlich die Idee hinter dem TileFetcher, dass der quasi ein Proxy ist, der sich ums Caching kümmert, sodass Du immer (auch im 30ms-Rhythmus) dort anfragen können sollst und immer die beste Version der angeforderten Kachel bekommst (zuerst Default-Kachel, sobald die richtige da ist, die echte Kachel).

[lootwitch]

wie zitiert man^^? EDIT: Indem Du ein einzelnes "größer als"-Zeichen vor das Zitat setzt (Kommentar von @floscher)

ich habs zuerst auch nicht geglaubt aber eine Liste zu führen wo ich direkt auf die richtigen Teils zugreifen kann ist echt besser ... (hat die Performance bei mir knapp verdoppelt als ich das getestet habe(ja ich habs sogar Zeitlich getestet^^)) ...

mit requestTile x y lod könnte das vielleicht sogar klappen dann brauchen wir die listener nicht und den zweite cache auch nicht. Da könnte viel code wegfallen wenn ich direkt aus dem cache lesen kann. Ich probiers gleich mal aus

Also die dritte Möglichkeit ^^

[MStumpp]

Die Tiles doppelt vorzuhalten macht natürlich wenig Sinn. Dafür ist der TileFetcher da. Das Listener-Konzept sollte als aynchrone Variante enthalten bleiben und meiner Meinung nach auch die bevorzugte sein. Die Map-Komponente fragt an Tiles an. Der TileFetcher gibt diese ansynchron zurück, in dem er die entsprechende Methode aufruft. Die Map-Komponente entscheidet dann, ob sie das übergebende Tile benötigt, rendert oder verwirft es...

[lootwitch]

ist klar es gibt jedoch ein kleines Problem

1. ist das zeichnen über die listener langsamer und führt öferts mal zu einen Thread Konflikt den es seit beginn gibt.
2. Jedes Teil hat zwei unterschiedliche x und y Coordinate x und y Coordinaten der OSM Karte und x und y Coordinate des Display

Während das Tile bei OSM die Coordinaten 3410 und 1233 hat das Tile auf den Display beispielsweise -1 und 2 Nunja jetzt muss berechnet werden wo das ganze liegt leider ist es Variabel wo der Display anfängt weil man ja reinzoomen kann. also fängt das Koordinaten Netzt bei -1 und -1 oder mal bei 0 und 0 an.

Deswegen wird eine Anfrage an den TileFetcher gestellt der schickt die Tiles die angezeigt werden über die listener. MapView berechnet die Coordinaten und spichert die Tiles als Referenz gepaart mit den Coordinaten ab. Deswegen werden die Tiles auch nicht doppelt gespeichert ... da habt ihr mich wohl missverstanden. Was doppelt gespeichert wird sind die Referencen und zwar bei beispielweise eine Anfrage an das Teil an der Stelle 0/0 muss der TileFetcher erst eins downloaden schickt deswegen die Referenz der DefaultKachel an den MapView der alle paar Milisekunden das Bild neuzeichnet. Jetzt kommt die echte Kachel zurück und wird auch als Referenz abgespeichert. So jetzt sind beide Referenzen da Defaultkachel und echte kachel und beide werden jetzt sofort nacheinander gezeichnet. Das ist das kleine Problem

So ich werde jetzt ne Art HashMap integrieren dann sollte sich das Problem lösen ^^

[MStumpp]

• Wenn du Referenzen speicherst, ist dann sichergestellt, dass der TileFetcher nicht auf den Objekten dieser Referenzen nicht irgendwelche Sache macht?
• Die Kommunikation mit dem TileFetcher läuft nur über die OSM Koordinaten, sowohl bei der Anfrage als auch die zurückgegeben Tiles, die MayDisplay spezifischen Koordinaten werden nur Map intern verwendet (so ist das wahrscheinlich eh)
• Ich denke ein Lösung ist besser, bei der die Referenzen auf die Tiles nicht in der MapKomponenten zwischengespeichert werden, sondern es wird im Moment des Aufrufes der Listener Methode entschieden, ob das/die Teiles gerendert werden oder nicht, die Referenzen werden nicht gehalten
• In der Map Komponente müsste dann nur zwischengespeichert werden, welcher Ausschnitt gerade angezeigt wird (zzgl. eines nicht sichtbaren Randbereiches), eintreffende Tiles, die innerhalb dieses Bereich liegen, werden gerendert; du kannst ja in der MapKomponente speichern, welche OSM Koordinate welcher Map Koordinate entspricht, denn diese Zuordnung muss natürlich irgendwo abgelegt sein

[lootwitch]

1. ja
2. ja
3. wie gesagt war die erste Implementierung funktioniert aber nicht gut
4. genau das wird ja gemacht (es wird bei jeder Aktion sei es verschieben oder zoomen oder ähnliches die tieles neu angefragt)

[lootwitch]

weiß jemand welche Art von HashMap hier die beste Performence hätte ? PS.: es geht XD

[MStumpp]

HashMap ist ja schon ne Implemenierung vom Interface Map. Bei der HashMap sind die keys halt nicht sortiert, bei TreeMap hingegen schon...

[lootwitch]

^^ sry ich meine natürlich Map es gibt ja noch mehr als HashMap und TreeMap ich glaub ich brauch sie nicht sortiert (es ist egal wo man mit dem zeichnen anfängt. Ich brauch schnelle Zugriffszeiten wenn ich durch iteriere

http://developer.android.com/reference/java/util/Map.html

deswegen hab ich jetz http://developer.android.com/reference/java/util/LinkedHashMap.html

[MStumpp]

wenn du bei jedem zugriff immer über alle keys iterierst, brauchst du die sortierung nicht, wenn du allerdings auf bestimmte keys zugreifen willst, z.B. Koodinaten, dann ist eine sortierte natürlich schneller log n (sortiert) vs. n (unsortiert)

[lootwitch]

jop wie gesagt die sortierung bruach ich ja nicht ^^ funktioniert scheinbar ganz gut hab auch mal die Wiederholungsrate hiochgesetzt es ist jetzt nicht flüssig wie ein game aber für ne Map darstellung würde mir es reichen

[lootwitch]

auch die POI darstellug ist mittlerweise annehmbar ..^^