Ungenauer Timer?

Plattformunabhängige GUIs mit wxWidgets.
JulesV
User
Beiträge: 16
Registriert: Sonntag 2. April 2006, 02:21

Beitragvon JulesV » Samstag 29. Juli 2006, 01:12

Okay das Service Pack 2 spielt keine Rolle für das Funktionieren des Timers. Ich habe keine Idee mehr...

An den Versionen vom Interpreter usw. kann es nicht liegen, da ich es mit einer py2exe-Datei getestet habe, die ihre Libarys selbst mitbringt...
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Samstag 29. Juli 2006, 08:37

JulesV hat geschrieben:Ich habe keine Idee mehr...

Hi JulesV!

Kleiner Wink mit dem Betonpfeiler :-) --> Hast du mein kleines Beispiel schon ausprobiert? Es funktioniert ohne Timer. Ich denke mal, dass du es auf einem "NICHT Echtzeit Betriebssystem", mit einer "NICHT Echtzeit Programmiersprache" kaum genauer hin bekommen kannst.

mfg
Gerold
:-)

PS: Korrekturwerte? An so etwas würde ich gar nicht erst denken. :-(
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Samstag 29. Juli 2006, 11:12

Hi!

Ich habe jetzt Tabulatoren im Quellcode verwendet, damit du es besser in dein Programm integrieren kannst. Ich rate dir aber, vier Leerzeichen zum Einrücken zu verwenden, damit es für andere, die sich an den Standard halten, einfacher ist.


Aus dem Beispielcode, den ich ein paar Beiträge vorher geschrieben habe, habe ich eine HighResolutionTimer-Klasse erstellt. Diese Klasse arbeitet ähnlich wie der Timer von wxPython. Die HighResolutionTimer-Klasse löst nach einer einstellbaren Zeitspanne das Event EVT_ON_HIGHRESOLUTION_TIMER aus und sendet dieses Event an das mit dem Parameter "parent" angegebene WX-Objekt.


Der Timer muss vor jedem Start neu initialisiert werden. Das erledigt die Methode "initialize", an die man auch den Intervall in Millisekunden übergeben kann. Stellt man den Intervall zu klein ein, dann kommt der Computer mit der Fülle an Events evt. nicht mehr nach. Das war bei meinem Computer z.B. bei 10 ms der Fall.


Die Teile im Code, die ich verändert habe, habe ich mit mehreren Leerzeilen vom anderen Code abgegrenzt, damit du ihn besser erkennst. Dann muss ich dich noch darauf hinweisen, dass es inzwischen üblich ist, Events mit der Methode "Bind()" an ein Objekt zu binden. Damit erübrigen sich die vielen ID-Nummern. Und das Frame-Objekt hätte ich persönlich eher als Klasse programmiert, so wie du es z.B. mit "DrawPanel" gemacht hast.

Quellcode ausgelagert, um das Forum zu entlasten:
http://gelb.bcom.at/trac/misc/wiki/Pyth ... uellcode01

mfg
Gerold
:-)

PS: Habt ihr wirklich in der Schule gelernt, den Code so zu strukturieren? Ich finde, da ist einiges verbesserungswürdig. Aber dafür wirst du wohl keine Zeit mehr haben. Deshalb gehe ich nicht mehr genauer darauf ein.
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
JulesV
User
Beiträge: 16
Registriert: Sonntag 2. April 2006, 02:21

Beitragvon JulesV » Sonntag 30. Juli 2006, 15:51

Also vielen Dank für den Highresolutiontimer. Der funktioniert unter windows wirklich gut. (Unter OSX braucht er viel zu viel rechenleistung, so dass die Animation nicht hinterher kommt und er also zu lange braucht. Eine Idee warum?).

Wir haben nicht gelernt den Code so zu strukturieren. Aber wir haben allgemein kein Python gelernt und vor allem keine wxwidgets. Ich musste das lernen während ich es benutzte, und daher ist der Code so ein bisschen Stück für Stück gewachsen und hat sich teilweise an verschiedenen Quellen im Internet orientiert. Kann also daher kommen, dass es dir etwas komisch vorkommt wie er strukturiert ist.

So, erstmal vielen Dank
Jules
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Sonntag 30. Juli 2006, 16:11

JulesV hat geschrieben:Unter OSX braucht er viel zu viel rechenleistung, so dass die Animation nicht hinterher kommt

Hi Jules!

Versuche mal diesen Code unter Windows und unter osX. Vielleicht hat es schon genügt, ein kleines "sleep(0.02)" einzubauen.

Um das Forum zu entlasten, habe ich den geänderten Code hier hinterlegt:
http://gelb.bcom.at/trac/misc/wiki/Pyth ... uellcode02

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
JulesV
User
Beiträge: 16
Registriert: Sonntag 2. April 2006, 02:21

Beitragvon JulesV » Sonntag 30. Juli 2006, 16:41

gerold hat geschrieben:Vielleicht hat es schon genügt, ein kleines "sleep(0.02)" einzubauen.

Leider nicht. Im Gegenteil, er reagiert sogar noch extremer. Er sowohl der Timer (die Zeitanzeige oben links) als auch die Animation springen ca. im Sekundentakt (etwas weniger als eine Sekunde) weiter. Das ist jetzt also wirklich eine Diashow. Und dazu kommt, dass es auch insgesamt länger braucht. Also bei einer Strecke und Geschwindigkeit die innerhalb von 6 Sekunden abgefahren sein müssten, braucht er mal 8,5 oder 8,6 Sekunden... ist nicht konstant. Sehr komisch irgendwie.
An der CPU-Last liegt es wohl nicht, er verbraucht nur 60-70%.

Ich habe nun auchnochmal die vorherige Version genauer untersucht. Auch da schien es doch nicht an der CPU-Last zu liegen, da es auch nur 80% waren. Entschuldige bitte die Fehldiagnose.
Hast du noch weitere Ideen?
Benutzeravatar
DatenMetzgerX
User
Beiträge: 398
Registriert: Freitag 28. April 2006, 06:28
Wohnort: Zürich Seebach (CH)

Beitragvon DatenMetzgerX » Sonntag 30. Juli 2006, 17:06

Könntest evtl deinen "eigenen" timer basteln

http://python.active-venture.com/lib/timer-objects.html

erstellst einen Thread, in welchem der Timer läuft. Dieser sendet jede Sekunde an den Hauptthread ein Signal (wx.PyEvent). Der Hauptthread wurschtelt dan irgend was damit. Und schlussendlich kannst du den Timer + Thread killen
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Sonntag 30. Juli 2006, 18:19

JulesV hat geschrieben:er reagiert sogar noch extremer.

Hi Jules!

Keine Ahnung! :K

mfg
Gerold
:roll:
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Freitag 4. August 2006, 09:49

JulesV hat geschrieben:er reagiert sogar noch extremer. Er sowohl der Timer (die Zeitanzeige oben links) als auch die Animation springen ca. im Sekundentakt (etwas weniger als eine Sekunde) weiter.

Hi JulesV!

Anscheinend arbeitet time.clock() nur unter Windows so wie von mir gewünscht. Siehe http://www.python-forum.de/topic-6775.html

Wenn du also time.clock() für den Mac durch eine andere Timer-Funktion austauscht, dann müsste es funktionieren.

lg
Gerold
:-)

PS: Wie ist's gelaufen? Waren die vier Jahre "umsonst"? ;-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
JulesV
User
Beiträge: 16
Registriert: Sonntag 2. April 2006, 02:21

Beitragvon JulesV » Freitag 4. August 2006, 10:49

gerold hat geschrieben:Wenn du also time.clock() für den Mac durch eine andere Timer-Funktion austauscht, dann müsste es funktionieren.

Danke für den Tip. So funktioniert es wirklich etwas besser. Zumindest ist er jetzt wirklich nach der korrekten Zeit am Ziel - nur die Animation "ruckelt" unter OS X trotzdem gnadenlos. Zuckelt mit etwas unter einer Aktualisierung pro Sekunde dahin. Naja. Am wichtigsten ist *erstmal* die Lauffähigkeit unter Windows. Unter Linux teste ich es heute Abend mal...

gerold hat geschrieben:PS: Wie ist's gelaufen? Waren die vier Jahre "umsonst"? ;-)

Am 10.8 ist die Abgabe... (allerdings muss ich bis dahin auch für 6 Klausuren lernen und habe keine Zeit mehr mich noch wirklich um das Programm zu kümmern. Aber ich betrachte es auch inzwischen als so gut wie fertig. (So gut wie fertig, weil eben noch keine 100%ige Plattformunabhägigkeit besteht und ich noch mit dem Prof. sprechen muss wie er gerne Dargestellt hätte dass man lieber bremsen sollte.)
Ich sage dann bescheid wenn ich das Ergebnis weiß :-). Bin aber was das Programm angeht sehr optimistisch, dank dir/euch! Vielen vielen Dank nochmal!

Stefan

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder