# Java Zeitgesteuert



## wakoz (10. Okt 2009)

Ich möchte das eine Aktion nach x Sekunden (besser noch Millisek.) durchgeführt wird. leider finde ich nichts wirklich passendes.

Aktuell nutze ich Java.swing.Timer, dieser benötigt aber etwas Zeit zum Durchlauf des codes.

Das Problem dabei: 

Ich erzeuge zu viele Events, so das die Events im Queue abgelegt werden und erst mit Verspätung abgearbeitet werden können.

Wenn ich weniger Events erzeuge macht meine GUI das nicht mit, da alle Events genutzt werden einen JSlider eine neue Position zu übergeben. Ist also die Rate über 50 Millisekunden Fällt das optisch auf, da der Slider deutlich springt. (50 millis bedeutet ja 20 Bilder die Sekunde und 24 müssten es sein)
________________________________________________________________________

Neben des Neuzeichnen des Sliders (nicht der ganze nur der Regler am Slider) werden noch drei weitere Aktionen abhängig vom Timer ausgeführt. Nach z.B. 200 Millisekunden wird ein log Eintrag (in eine Liste) geschrieben, nach z.b. 3 Sekunden soll ein ImageComponent befüllt und nach weiteren z.b. 6 sek. wird die selbe ImageComponent geleert. die Aktionen des Zeichnens werden natürlich in der GUI ausgeführt, aber immer noch im selben Programm. 

Die ImageC. wird mit einem JPEG Bild gefüllt, diese werden durch das Prog. nicht bearbeitet. (Pixel Höhe und breite 1zu1)


Was kann ich machen, damit ich eine Wiederholungsrate kleiner 50 Millisekunden machen kann?

Damit der Slider flüssig verschoben (ohne springen) aber der/die? Queue nicht so voll wird. So das es sich auf die anderen Timer Events auswirkt. Aktuell habe ich, wenn wenn nach z.b 3 Sekunden was passieren soll, mehrere Sekunden Abweichung.


Zwei Ideen hätte ich, weiß aber nicht ob diese gehen.

Einmal = Threading -> der Timer / Eventhandler wird in einen eigenen Thread ausgelagert so das dieser Parallel läuft. Bin mir aber nicht sicher wie sich dies mit der GUI vereinbaren lässt, da Variablen aus der GUI abgerufen werden müssen die zur Laufzeit zum Zeitpunkt des Timer events erzeugt werden können. Bzw. ob man einen Eventhandler überhaupt ausgelagert werden kann.

Zweitens = Erzeugung mehrerer Timer -> so das jedes Aktion einen eigenen Timer besitzt, nicht alle Aktionen müssen alle paar Millisekunden ausgeführt werden. Wobei ich nicht weiß was mit der Queue ist, reihen sich die Events dann alle hinten an? Oder werden diese Timer Eventhandler als eigenständige Threads behandelt, die Parallel laufen?


----------



## arthur177 (11. Okt 2009)

Wie wäre es mit

```
Thread.sleep(millisekunden);
```
?
Oder du vergleichst in einer Schleife einfach die Anzahl der vergangenen ms mit CurrentTimeMillis
	
	
	
	





```
long millisToWait = 1000;
        long millis = System.currentTimeMillis();
        while((System.currentTimeMillis() - millis) < millisToWait) {
            // Do nothing
        }
```
Wobei ich die zweite Möglichkeit nicht getestet habe. Habe es nur mal gelesen


----------



## wakoz (11. Okt 2009)

arthur177 hat gesagt.:


> Wie wäre es mit
> 
> ```
> Thread.sleep(millisekunden);
> ...


Danke für deine Vorschläge.
Leider ist schlafen keine alternative, da man damit den gesamten Thread lahm gelegt wird. Was nicht mit den neu zeichnen nicht vereinbar ist. 

Dein Zweiter Vorschlag ist funktionstüchtig nur macht er das selbe wie thread.sleep(millis). Was ähnliches hatte ich mir anhand der Performance Test Beispiele die ich mit Google gefunden hab gedacht habs dann aber wieder verworfen weil es ähnlich ungenau wird als das was ich jetzt hab.:noe:


leider bin ich nicht sicher im Umgang mit threads, sonst würde ich einfach sagen für jeden Timer ein Thread der wiederum der Mutter (das Programm was den Thread erzeugte) sagt wann was zu tun ist.

Also mein Programm jetzt erzeugt Threads die einen Timer Laufen lassen. Dieser Timer ruft Methoden aus dem Mutter Thread auf die dann die Aktionen ausführen. Aber ich weiß nicht wie oder ob das so einfach geht.

Ich meine ob Threads einfach Methoden anderer Threads nutzen (aufrufen) können. Und ob ich damit das Problem nicht vom Timer zur GUI verschleppe? Wobei ich weiß wenn der Timer nicht so oft (also anstatt alle 50 millis alle 100 millis) events auslöst past das mit den anderen Zeiten besser! Aber ja leider mit der GUI nicht

MfG


----------



## faetzminator (11. Okt 2009)

Wie wärs mit


```
long millis = System.currentTimeMillis();
// das was du tun willst
Thread.sleep(System.currentTimeMillis() - millis);
```


----------



## Unregistriert (11. Okt 2009)

faetzminator hat gesagt.:


> Wie wärs mit
> 
> 
> ```
> ...



das heißt doch nur das der thread so lange schläft wie er gebraucht hat von erzeugung der millis bis zum thread sleep.

Aber in Verbindung mit einer while true und der Angabe wie lange gewartet werden muss... könnte dies in einem seperaten thread funktionieren


----------



## wakoz (11. Okt 2009)

Danke für eure Vorschläge, ich habe eben erfolgreich ein Thread eingefügt und es läuft nun etwas besser :applaus: 

Java.swing.Timer funktioniert zuverlässig solange die Queue nicht durch zu viele Evnents verstopft wird 

gleich werde ich noch eine Thread einfügen, in der Hoffnung das dann alles wie gewünscht funktioniert. Naja hoffe ich bekomme dies hin :bahnhof:


----------



## tuxedo (13. Okt 2009)

Wie wär's mit nem ThreadPool? Oder müssen alle "Events" durch den einen Thread?

- Alex


----------



## wakoz (14. Okt 2009)

tuxedo hat gesagt.:


> Wie wär's mit nem ThreadPool? Oder müssen alle "Events" durch den einen Thread?
> 
> - Alex



mal abgesehen davon das ich das Thema auf erledigt hab

Das war ja eine meiner Fragen, ob ich die Events / Eventhandler vom Hauptprogramm trennen kann. Und Ja es geht :toll:

Ich kann jetzt gerade mit dem begriff Threadpool nichts anfangen, aber habe nun für jedes Event (die eigendlich alle zusammen gehören) einen einzelnen Thread. Das Problem hat sich etwas verschleppt, da die GUI nun von einem Thread sehr doll angesprochen wurde und dadurch die Performance wieder in den Keller ging! Aber das hab ich durch Verringerung der Events dieses Threads gelöst. Nicht gerade fein aber vertretbar. 

Dadurch hat sich bei mir eine Neue Frage an das Forum ergeben, aber die stelle ich irgend wann in einem Anderen Thread


----------

