nur, damit ich’s schon mal $irgendwo hingeschrieben habe … :
ist es möglich irgendwie ne Art Fortschrittsbalken oder zumindest einen dreheden Kreis/„Throbber“/whatever einzubauen.? ich hab jetzt schon öfter Rückmeldungen von verstörten Benutzern gehört, die es irritierend finden, wenn die (Web-)Seite beim Aufruf einfach nur weiss bleibt und es dann irgendwann einfach »plopp« macht und die Karte ist da…
Es liegt aber nach meinen Tests nicht am Netzwerk.
Die Daten kommen zuerst an (man kann im Browser ja in der Netzwerkanalyse schauen, wann nodes.json und graph.json da sind), aber dann dauert es immer noch ein paar Sekunden bis die Karte auftaucht.
Ja, der „Client“ verarbeitet die Daten noch. Das will ich in Zukunft auch noch verkürzen, indem der Server mehr von der Arbeit abnimmt und dann auch cached.
Das ist richtig die Daten müssen ja erst verarbeitet werden.
Im Falle des Hessen-Meshviewers
werden 12 Dateien geladen
Es wird geschaut welche Version der nodes.json vorliegt (Frankfurt und Wiesbaden benutzen meine ich V2 der Rest V1) das heisst es werden daten umgebaut auf die andere json version / dabei werden alle unknown nodes gekickt.
Gut bei Hopglass gibts den Aufriss nicht da es nur ein Datenformal gibt
Gibts eigentlich ein Community die so 2500 Knoten hat und hopglass einsetzt ?
Der Meshviewer hatte bei der Anzahl drastische performance Probleme.
Benötigt zwar immer noch viel Leistung aber es geht mittlerweile.
Ich habe bei meinem jüngsten Tests JavaScript/ECMAScript spielereien durchaus festgestellt, dass da auch bei uns noch was geht. Allerdings müsste man dazu auf das V2 Format umsteigen. In manchen Dingen vorteilhaft in anderen weniger. Sollten wir nochmal prüfen.
Könnte zumindest in allen Browsers die V8 (Chrome, Opera, etc.) nutzen durchaus ein paar (~50) ms Unterschied (pro Schleife) machen.
Das Hauptproblem ist und bleibt die grafische Verarbeitung die schleppend ist, da viel nach gerendert wird (In der logischen Ansicht) und das Laden der Daten an sich.
Die Frage die sich hier stellt ist, wie viel will man wirklich von der Clientseite weg haben? Ich finde nämlich das eigentlich schöne am Meshviewer, dass er komplett clientseitig läuft. (Hat natürlich wie man merkt seine Tücken)
Wenn man nicht alles abgesehen der Anzeige auf die Serverseite Auslagern will (Heißt auch serverseitig die Filter verarbeiten) sehe ich leider wenig einsparpotential was Daten angeht
Ich überlege mir mal wie man das Caching besser gestalten könnte
Bevor man nicht alle Clients hat (also die Nodelist.json), vorher weiss der Client nicht, welche Karte (Mitte, Zoomstufe) er zeichnen soll.
Und dafür muss die Datei halt erstmal da sein, wird vom webserver ja hoffentlich gepackt übertragen.
Das kann man gerne auch für sehr viel mehr Knoten übertragen, das sollte nicht das Problem sein, aber um die Nodes so wie in der aktuellen Version mit Filtern etc. verwalten zu können, sind mehr Informationen auf Anhieb erforderlich. Hier liegt der Hase im Pfeffer.
Ich experimentiere gerade mal mit den neuen Features von HTTP/2.0 - i.e. Server-Push/Propose…
lies: der Server (wahlweise auch das HTML-Skelett selbst) sagt beim Abruf der index.html: »BTW: Du Browser wirst gleich noch die nodes.json und die graph.json brauchen… die kannst du dir im Side-Channel schon mal im Hintergrund laden…« (HTTP/2.0 implementiert einen multiplex-Stream)
Wenn dann die app.js soweit ist selbst die JSONs per XHR zu holen, dann liegen die potentiell schon im Browser-Cache und können direkt geparsed werden - sofern auch die Expire/Cache-control Header das zulassen…
Der blöde Autoformater m) hält ich lassen sollen so kann man anhand des diff’s nichts nachvollziehen was geändert wurde
Eine Datei muss ich noch mal überarbeiten dann kann ich committen → dürfte so morgen Abend werden
:
