Graph - bei sich verändernden Werten Skalierung anpassen

  • Ich wollte jetzt zu meiner Copy-Funktion auch eine Graph-Anzeige einbauen.

    Soweit auch unproblematisch. Ich hatte vor Jahren, um mir den Umgang mit GDI zu vereinfachen, ja mal eine UDF dafür erstellt. Ist sicher für diese Anwendung overdressed, aber läuft.

    Mein Problem liegt hier:

    Beim Kopieren ist die Kopiergeschwindigkeit ja im Bereich von 0 bis ... MB/s.

    Die zu zeichnenden Punkte sind immer als Prozentwerte anzugeben, max. Zeichenbereich = 100%. Nur auf welchen Wert soll ich die 100% referieren? Kopieren auf der Festplatte ist meist um die 80 MB/s, wenn ich da 150MB/s = 100% setze ist das übersichtlich. Auch wenn der Speed auf 10 MB/s absackt. Kopieren auf externe Datenträger kann aber deutlich langsamer sein, im KB-Bereich. Das würde dann gar nicht mehr angezeigt werden.

    Ich würde jetzt den Speed auswerten und beim Erreichen von Schwellwerten eine neue Grenze für die 100% setzen.

    Oder habt ihr andere Ideen?

    Hier mal eine lauffähige Simulation. Die erforderliche "LivingGraph.au3" ist angehängt.

    BTW: Random() ist schon sehr seltsam. Spätestens nach 3 Minuten sind die simulierten Werte nur noch am Maximum und bleiben dort hängen.

    EDIT: Ich hab schon zu lang nicht mehr damit gearbeitet. Es sieht so aus, als ob 0 oben ist?! Was hab ich denn da vergurkt? GDI+ ist nicht wirklich meine Kernkompoetenz. :D

    Prozentwerte war Quatsch, Pixelposition wie üblich, nach unten größer werdend. - OK, das ist dann nur ein Umrechnungsproblem.

    EDIT 2: Also die _RandomTransferSpeed() ist so nicht sehr sinnvoll, muss ich nochmal überdenken. - Ist aber nicht das Kernproblem.

    EDIT 3: Die Funktion _RandomTransferSpeed() ist jetzt angepasst, aber läuft nach einiger Zeit gegen 0. Seltsam.

  • Ich bin mir grad nicht ganz sicher, wie windows es macht, aber macht es nicht sinn, einfach immer das aktuelle maximum zu nehmen?

    Wenn nen höherer Wert kommt wird die Grafik größer und es gibt nen neues maximum. Ist ja auch relativ sinnvoll, weil Festplatten normal mit der Zeit langsamer speichern, je mehr Daten ankommen (sobald caches,... voll sind).

    Daher sind die größten Werte eher am Anfang.

    Steam arbeitet bei den Downloads aber auch so, glaub ich.

  • Ich würde sowas vorschlagen:

  • BugFix 2. September 2022 um 15:23

    Hat das Label von [ offen ] auf [ gelöst ] geändert.
  • Hier noch eine Version mit Beschriftung:

  • Auch, wenn Du die Aktualisierung nur z.B. jede Sekunde vornimmst?

    Weniger als 0.1 s ist nicht sinnvoll, da dann zu wenig Werte generiert werden und kein an- u. absteigender Graph, sondern eine kurze wilde Zick- Zacklinie entsteht.

    Ich mach mir mal Gedanken, wie ich das in einen externen Prozess/anderen Kern auslagern kann.

  • Weniger als 0.1 s ist nicht sinnvoll, da dann zu wenig Werte generiert werden und kein an- u. absteigender Graph, sondern eine kurze wilde Zick- Zacklinie entsteht.

    Ich mach mir mal Gedanken, wie ich das in einen externen Prozess/anderen Kern auslagern kann.

    Stimmt! Ich erinnere mich an mein Programm "FlashTest". Da habe ich das schreiben/lesen auch in einen Slave-Prozess ausgelagert.

    Mit Hilfe der MailSlot-UDF habe ich die Kommunikation zwischen dem Master und dem Slave gelöst. Mit MailSlots können die Prozesse asynchron kommunizieren. Das ist wichtig, damit keiner der beiden Prozesse durch den anderen ausgebremst wird, weil der gerade die Nachricht abholt.

    Aber als FileCopy-UDF wird das wohl sehr heftig werden, wenn es überhaupt irgendwie geht. :/

  • Aber als FileCopy-UDF wird das wohl sehr heftig werden, wenn es überhaupt irgendwie geht.

    Ich überlege gerade, das mit wChart in Nim zu schreiben und auch dort den async Prozess zu nutzen. Zur Kommunikation mit SciTE hatte ich das schon genutzt (async).

    wChart nutzt auch GDIplus, aber halt wesentlich performanter.

    Aber das hat keine Eile, werde ich mal immer so nebenbei weiter verfolgen.