Na, lass uns mal abwarten wie die angekündigte ZIP-Beschleunigung in der nächsten Version läuft. Momentan sind ja auch noch doppelt so viele Datein im ZIP wie nötig (für jede Bitmap eine eigene KAL-Datei). Ich wüsste nicht, warum ZIP wesentlich langsamer sein sollte. Da ist doch ein Datei-Index drin. Am besten wäre natürlich, wenn die aktuelle ZIP-Datei ständig geöffnet bleibt, damit der Index nicht für jede Kachel neu gelesen werden muss. Ist das möglich? D.h. die Frage ist, ob die verwendete ZIP-Library derartige Funktionen bietet.
-
-
-
Zitat
Original von frank334
Na, lass uns mal abwarten wie die angekündigte ZIP-Beschleunigung in der nächsten Version läuft. Momentan sind ja auch noch doppelt so viele Datein im ZIP wie nötig (für jede Bitmap eine eigene KAL-Datei). Ich wüsste nicht, warum ZIP wesentlich langsamer sein sollte. Da ist doch ein Datei-Index drin. Am besten wäre natürlich, wenn die aktuelle ZIP-Datei ständig geöffnet bleibt, damit der Index nicht für jede Kachel neu gelesen werden muss. Ist das möglich? D.h. die Frage ist, ob die verwendete ZIP-Library derartige Funktionen bietet.Jepp,
ich freue mich über jede Beschleunigung.
Ob ZIP langsamer ist oder nicht und warum ist mir eigentlich egal - entscheidend ist was die Stoppuhr sagt und die läuft nunmal bei mir mit vielen Karten im ZIP deutlich länger!
Aber wenn ich richtig gelesen hab muß wohl Peter eine Lösung schon parat haben.Und da Glopus mit mehr wie 40 ZIP's ohne Probs hantiert ist für mich das Problem mit dem Kartenwechsel eh erledigt, da nur noch vor und nach Urlauben dies ansteht!
Gruß
Silver -
Ich habe mit GMM mein Umkreis neu gekachelt und habe dabei gleich die Kachelgröße 250x250 genommen.Daraus wurden 2500 Kacheln die ich dann auch in ein Zip File gepackt habe. Gesagt getan hab ich es gleich getestet.
Es war schlimmer als vorher. Der Aufbau bis er meine Position auf der Karte anzeigen konnte hat mehrere Minuten gedauert. Mit flüssigem anzeigen der gefahrenen Strecke war gar nicht zu denken.
Jetzt bin ich am überlegen woran es liegen könnte? Zuviele Kacheln in einer Zip File?
Kann es an der Komprimierung liegen?
Oder sind es zu kleine Kacheln? Wie verhält sich Glopus beim allokieren des Speichers? Gibt er den Speicher wieder frei denn er für eine Kachel genommen hat die nicht mehr notwendig sind? Oder hat Glopus eine feste Speichergrösse die er für seine laderei benutzt?
Ich werde jetzt versuchen einmal weniger Kacheln in eine Zip Datei zu packen. Was macht da Sinn? Und wie gross sollten die Kacheln sein? 1000Pixel oder doch kleiner?
Mein xda mini hat nicht besonderst viel Speicher zur Verfügung. Wenn er frisch gestartet ist hat er für den Daten und Programmspeicher noch insgesamt 36Mb zur Verfügung.
lg
Danjel
-
Zitat
Original von Tyrone
Kann es an der Komprimierung liegen?Hi,
es muss ein unkomprimiertes Zip-File sein.
Gruß
H.-J. -
Zitat
Original von Tyrone
Oder sind es zu kleine Kacheln? Wie verhält sich Glopus beim allokieren des Speichers? Gibt er den Speicher wieder frei denn er für eine Kachel genommen hat die nicht mehr notwendig sind? Oder hat Glopus eine feste Speichergrösse die er für seine laderei benutzt?
DanjelIch hatte mir mal Performance-Grafiken von der PC-Version angesehen, mittels Sysinternals ProcessExplorer. Was mir dabei aufgefallen war:
- je mehr in der Karte herumgescrollt wird, desto größer wird der "Physical Memory: Working Set Private", ohne das etwas freigegeben wird. Das geht in die hunderte MB. Beim GeoGrid Top50 Viewer passiert das nicht, der bleibt konstant bei etwa 20MB Private Bytes.
- im Vergleich zu anderen Win32-Programmen geht sehr viel Zeit auf Kernel-IO drauf (etwa 50%).
Darauf meine Vermutung:
- bei Kachelwechsel wird die Speicher entweder nicht freigegeben oder Windows hat mal wieder einen Bug
- Die viele Kernel-IO könnte könnte dadurch entstehen, dass nicht die Kartenkachel ganz in den Speicher gelesen wird, sondern Stückweise im File gelesen wird. Evtl. könnte man das beschleunigen.Das ist aber jetzt reine Spekulation, da ich weder die Funktionsweise von Glopus kenne, noch die von Windows-CE.
Ganz allgemein könnte man mit Index- und Hashtabellen viel optimieren. Daher denke ich, im Prinzip sollte Glopus nicht wesentlich langsamer sein als OziExplorer, wenn alle Optimierungsmöglichkeiten ausgeschöpft werden. Voraussetzung ist immer, dass alles in den Speicher passt und nichts ausgelagert werden muss. Ich habe immer noch nicht verstanden, wie es sich mit RAM und Flash-RAM bei WinCE verhält. WM5 hat das angeblich wesentlich geändert.
Gut, ein wenig Kompromiss gehe ich ein, lieber eine Sekunde mehr beim ZIP-Kachelwechsel als mit tausenden Kacheldateien aus verschiedenen Regionen herumzuhantieren. Da habe ich kaum noch durchgeblickt.
-
Ich habe WIndows Mobile 2003 mit 57Mb Arbeitsspeicher.
CPU: Intel PXA272 mit 400Mhz.Selbstverständlich ist die Zip Datei ohne Komprimierung. Ich meinte vielmehr die Bildkomprimierung die ich mit pngout durchgeführt habe.
lg
Danjel
P.S Ich werd versuchen die Zip Datei aufzuteilen, so dass nur 250 Kacheln in einer Zip Datei sind.
-
ZitatAlles anzeigen
Original von frank334
Ich hatte mir mal Performance-Grafiken von der PC-Version angesehen, mittels Sysinternals ProcessExplorer. Was mir dabei aufgefallen war:
- je mehr in der Karte herumgescrollt wird, desto größer wird der "Physical Memory: Working Set Private", ohne das etwas freigegeben wird. Das geht in die hunderte MB. Beim GeoGrid Top50 Viewer passiert das nicht, der bleibt konstant bei etwa 20MB Private Bytes.
- im Vergleich zu anderen Win32-Programmen geht sehr viel Zeit auf Kernel-IO drauf (etwa 50%).
...
Ganz allgemein könnte man mit Index- und Hashtabellen viel optimieren. Daher denke ich, im Prinzip sollte Glopus nicht wesentlich langsamer sein als OziExplorer, wenn alle Optimierungsmöglichkeiten ausgeschöpft werden.
Ich benutze beide Programme, die aber mit unterschiedlichen Anforderungen. Momentan ist für mich der OziExplorer fürs Navigieren mit größeren Karten geschwindigkeitsmäßig dem Glopus weit überlegen. Karten mit 10 MB und mehr sind kein Problem und werden wesentlich schneller geladen als eine kleine Kachel bei Glopus.
Glopus wiederum hat eine Unmenge von Einstellungsmöglichkeiten, die das Navigieren als Fußgänger bei kleinen Entfernungen erleichtern. Ebenso toll sind Detaillösungen, wie die Entfernungsmessung in der Karte etc. Da benötigt man in der Regel auch nur kleinere Kacheln einer Karte.
Da der Peter das Forum hier aufmerksam verfolgt, denke ich, wird sich da sicher einiges noch ändern und weiterentwickeln. Das war für mich ein Grund Glopus auch sofort zu registrieren, weil das Projekt lebt und weiterentwickelt wird.
-
Bitte nicht zu viel Zeit in die zip Optimierung stecken, in der nächsten Version ist u.a. die zip Performance wieder ganz anders. Zudem verliert die letze Version bei gezippten Kacheln u.U. Speicher (liegt an einer fehlerhaften Systemfunktion). Ich habe das auch erst nach dem Release gemerkt und dachte es liegt am zip Algo, ist aber nicht so.
Außerdem bitte nicht mit der Windows Glopus Version testen und Rückschlüsse ziehen. Windows arbeitet in der Speicherverwaltung ganz anders und Glopus ist für den PPC geschrieben. Eine richtige Windows Version würde ich ganz anders bauen. -
Hallo Peter,
wie händelt denn Glopus den Speicher? Allokiert er eine feste Grösse und verwirft die nicht benötigten Kacheln oder holt er sich immer mehr Speicher?
lg
Danjel
-
ZitatAlles anzeigen
Original von Tyrone
Hallo Peter,wie händelt denn Glopus den Speicher? Allokiert er eine feste Grösse und verwirft die nicht benötigten Kacheln oder holt er sich immer mehr Speicher?
lg
Danjel
Willst du weiterprogrammieren? Keine feste Größe, Glopus richtet sich nach dem verfügbaren Speicher und gibt auch dynamisch frei, wenn Speicher knapp wird. -
Zum Programmieren fehlt mir das Wissen dazu. Bin beruflich sehr stark in SAP eingespannt. Da hab ich nicht die nötige Kraft mich ins Programmieren einzuarbeiten.
Wollen schon aber nicht können...
lg
Danjel
-
Peter, holst du eigentlich schon vorausschauend die komprimierten Files in den Speicher? D.h. in Bewegungsrichtung die nächste Kachel, bevor sie angezeigt wird. Mit so einer Systematik dürfte man ja eigentlich überhaupt keinen Geschwindigkeitsnachteil von ZIP-Karten bemerken. Und so eine typische 1000'er Kachel von 400kB PNG passt sicher noch ins RAM.
Oder hat WM5 gar kein RAM mehr? Ich hatte irgendwo gelesen, dass alles jetzt Flash wäre. Aber das kann ich mir auch nicht so recht vorstellen, da die Zyklenzahl sehr begrenzt ist und die Geschwindigkeit auch um Größenordnungen unter der des RAM liegt. Die Speicheranzeige des WM5 verstehe ich auch nicht, "Programmspeicher"? Das kenne ich nur von DSP, dass Code und Data in verschiedenen Bänken liegen. Kann mir jemand die Erleuchtung bringen?
-
Bei meinem Versuch mit den Kacheln und pngout konnte ich ein Erfolg verbuchen. Habe die 2500 Kacheln in jeweils 10 Zip Dateien gepackt. Und auf einmal läuft Glopus mit den Karten flüssig.
Nur das andere Problem ist das meine Top50 karten die ich gekachelt und mit pngout gearbeitet hab der untere drittel Streifen beinhalten. Somit ist die Karte nicht lesbar. Werde jetzt versuchen nur mit GMM zu konvertieren. Vielleicht sind dann die Karten lesbar.
werde berichten.
lg
Danjel
-
Zitat
Original von Tyrone
Nur das andere Problem ist das meine Top50 karten die ich gekachelt und mit pngout gearbeitet hab der untere drittel Streifen beinhalten. Somit ist die Karte nicht lesbar. Werde jetzt versuchen nur mit GMM zu konvertieren. Vielleicht sind dann die Karten lesbar.
Schickst du mir mal eine der Kacheln? -
Zitat
Original von Tyrone
Bei meinem Versuch mit den Kacheln und pngout konnte ich ein Erfolg verbuchen. Habe die 2500 Kacheln in jeweils 10 Zip Dateien gepackt. Und auf einmal läuft Glopus mit den Karten flüssig.Der Erste der meine Beobachtung bestättigt, das die Anzahl der Karten im ZIP einen Einfluß auf den Kartenaufbau hat und dies durch Aufteilen der Karten auf mehere ZIP's gelöst werdne kann.
ZitatOriginal von Tyrone
Nur das andere Problem ist das meine Top50 karten die ich gekachelt und mit pngout gearbeitet hab der untere drittel Streifen beinhalten. Somit ist die Karte nicht lesbar. Werde jetzt versuchen nur mit GMM zu konvertieren. Vielleicht sind dann die Karten lesbar.Beobachtung kann ich bestättigen, die letzte Reihe beim Zerteilen einer Karte wird falsch kallibriert, allerdings benöige ich dies kaum, deshalb hats mich bis jetzt noch nicht gestört!
Gruß
Silver