[archimedes] Re: Fragen zum C-Programm Uhrzeit
- From: Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx>
- To: archimedes@xxxxxxxxxxxxx
- Date: Thu, 05 Jan 2017 20:12:06 +0200
In message <3ebca6f955.Toni@xxxxxxxxxxxxxxxxxxxxxxxx>
"Anton Reiser" <anton-reiser@xxxxxxxxxxx> wrote:
In message <721b92f955.Alex@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx>
wrote:
[flackernde Uhrzeit]
Du kannst das flackern ein gutes Stück reduzieren, wenn Du
while (newtime - oldtime >= 0)
statt
while (newtime - oldtime > 0)
verwendest.
Sonst wird das Icon unnötigerweise mindestens zweimal in der Sekunde
gezeichnet.
Ich hab's versucht zu verstehen. Also nachzuvollziehen. Aber an irgend
etwas scheitert es.
Ich verstehe das so: Die eingebaute Laufzeituhr zählt in Stufen von
1/100 Sekunden, d. h. in Abschnitten (Zeitintervallen) von 10
Mikrosekunden weiter.
^^^^^^^^^^^^^
Ich meinte hier doch wohl hoffentlich Millisekunden?
Nehmen wir z. B. an, new steht bei 100, old bei 0. Das ist der Abstand
von 1 Sekunde.
Dann wird bei while (new - old >= 0) die Berechnung old = old + 100
_zweimal_ durchgeführt (bei (new - old > 0) hingegen nur einmal), so
dass old dann um den Wert 200 erhöht wird, bevor die Schleife verlassen
wird. Für mich heißt das jetzt aber, dass die nächste Aktualisierung des
Symbols dann erst nach 2 Sekunden erfolgt. Das ist aber offensichtlich
nicht der Fall. Denn dann müsste ja bei der Anzeige jeweils 1 Sekunde
übersprungen werden.
Bei wimp_poll_idle() gibtst Du an, wann sich der wimp wieder melden
soll, also ein Zeitpunkt in der Zukunft.
Ist Jetzt 100, dann ist eine Sekunde weiter in der Zukunft 200.
Genau das, was bei >= 0 rauskommt.
Beim Test > 0 wird zum Zeitpunkt 100 oldtime auch auf 100 gesetzt,
wimp_poll_idle() mit 100 aufgerufen.
Der Wimp kommt ziemlich schnell wieder zum Zeitpunkt 101 zurück (da
ist 100 vorbei).
Es hat sich nichts für die Uhrenanzeige geändert, aber erst jetzt wird
oldtime auf 200 hochgesetzt.
So ganz verstehe ich deine Antwort hier leider nicht. Aber es deckt sich
anscheinend mit dem, was ich eben kapiert habe (oder kapiert zu haben
glaube). Bitte korrigier(t) mich, wenn ich falsch bin!
Also. Ich möchte es nochmals in eigenen Worten erklären:
Ich habe die Laufzeituhr jetzt 'mal mit Hilfe von zwei Symbolen (Icons)
sichtbar gemacht, um oldtime und newtime ausgeben zu können. Dabei
stellte ich folgendes fest:
Beim erstmaligen Start des Programmes sind oldtime und newtime
blöderweise gleich. Das heißt dann wohl, dass die Bedingung
(newtime - oldtime ) > 0
nicht erfüllt ist und deshalb wenigstens beim ersten Mal oldtime nicht
um 100 höhergesetzt wird. Das Programm wird damit innerhalb der nächsten
10 Millisekunden bzw. sobald wie möglich wieder angesprungen. Das
geschieht so lange, bis sich die Laufzeituhr um wenigstens 10
Millisekunden erhöht hat. Danach erst ist nämlich die Bedingung
(newtime - oldtime ) > 0
erfüllt.
Oldtime wird also dann erst beim nächsten Durchlauf um 100 hochgesetzt,
weil erst ab hier die Bedingung newtime - oldtime > 0 erfüllt ist.
newtime wurde aber vom System auf jeden Fall zwischenzeitlich um
wenistens 1 erhöht. Damit hinkt newtime oldtime (_nach_ der Erhöhung
oldtime = oldtime + 100) durch die erfolgten sofortigen ersten Ansprünge
des Programms aber nur noch maximal 990 Millisekunden hinterher.
Wir haben durch die unverzüglichen erfolgten ersten Durchläufe
wenigstens 10 Millisekunden (oder mehr!) Abstand zwischen
newtime und oldtime verloren! Ab jetzt schreitet oldtime dann aber nur
noch maximal um 990 Millisekunden der Laufzeituhr bzw. newtime voraus.
Das heißt, das Programm wird dann schon rein theoretisch mindestens alle
990 Millisekunden angesprungen (oder schneller). Das wären dann die von
dir erwähnten 2 Neuzeichnungen pro Sekunde.
Wenn man jetzt aber die Bedingung
(newtime - oldtime) >= 0
stellt, so ist diese Bedingung bereits schon beim ersten Durchlauf
erfüllt. Damit wird gleich beim ersten Durchlauf oldtime um 100 erhöht.
Damit ist der nächste Ansprungpunkt rein theoretisch erst in einer
Sekunde (100).
Das Problem ist also der erste Durchlauf bzw. die Tatsache, dass oldtime
und newtime zu Anfang identisch sind und damit die Bedingung (newtime -
oldtime) > 0 bei den ersten Durchläufen nicht erfüllt ist.
Puh. Das zu verstehen war ein Ding. Wichtig ist außerdem zu verstehen,
dass sich die Laufzeituhr ab dem Einschalten um alle 10 Millisekunden
erhöht und man immer die nächste, absolute Zeit angeben muss. Wenn der
jetzige Ansprungzeitpunkt z. B. bei 5000 liegt, müsste dann der nächste
Ansprung bei 5100 liegen (und dieser Wert muss bei wimp_poll_idle
angegeben werden).
Hm. Vielleicht sollte man mal die Formel in den Programmers Reference
Manuals verbessern.
Denk dran, Zeitangabe bei wimp_poll_idle ist ein Wunschwert!
Ja.
Gibt es vor Deinem Wunschzeitpunkt einen für Dein Programm relevanten
Event, meldet sich der Wimp vorher.
Bei Deinem Programm typischerweise OpenWindow, PointerEnterWindow,
PointerLeavingWindow ...
Auch dann wird nach Deinem Code ein Neuzeichnen angestossen, auch wenn
sich der String nicht geändert hat.
Events, die nicht interessieren, sollten per Poll-Maske ausgeblendet
werden.
Stimmt. Ausgerechnet bei diesem Programm habe ich die Pollmaske noch
nicht angepasst. Schande über mein Haupt. Irgendwo habe ich das gemacht,
aber scheinbar (noch) nicht bei diesem Programm. Ui. Nachholen!
Wird der Wimp durch ein anderes Programm aufgehalten, meldet er sich
er später. In diesem Fall langweilit, die Uhr bleibt halt stehen und
macht denn eine Sprung auf die aktuelle Zeit.
Danke nochmals!
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Hilft dir keiner, hilf dir selbst.
Other related posts:
