ich habe ein programm geschrieben um eine dreidimensionale Anischt zu erzeugen…
Ich zeichne dabei auf eine von JPanel abgeleitete Fläche.
Ich habe mehrere JSliders über die gewisse Winkel eingestellt werden können.
Wenn man die verändert, werden die aktuellen Werte ausgelesen und dementsprechend ein Bild erstellt, also quasi live während dem Verschieben…
das Bild fordere ich über repaint() an.
Das klappt auch ganz gut, nur manchmal wenn ich z.b. relativ schnell daran rumzieh bleibt mir die ganze Anwendung mit 100% CPU Last stehen und nur noch den Prozess abzuschiessen hilft…
Wenn ich im Debugger das Programm dann anhalte steht er mir in der nativen Methode
sun.java2d.loops.IntDescreteRenderer.devFillPolygons()
Ich dachte zunächst das passiert wenn er nicht nachkommt mit dem Erzeugen der Bilder, aber gerade eben ist er mir auch hingestanden als er nur eins mit genügend Zeit hätte berechnen sollen. Das lustige ist auch, dass bei einer automatisierten Sequenz die absichtlich 100% CPU Last erzeugt und ca. 70 frames per second liefert, noch nie ein Hänger passiert ist…
hat jemand Ahnung woran das liegen kann? bin leider sehr ratlos…
Du sprichst von einer Native Method, da frag ich mich, ob die Bibliothek von Sun vielleicht ein Problem mit Deinem grafikkartentreiber hat. Hast Du es mal auf einer anderen Maschine probiert?
Du sprichst von einer Native Method, da frag ich mich, ob die
Bibliothek von Sun vielleicht ein Problem mit Deinem
grafikkartentreiber hat. Hast Du es mal auf einer anderen
Maschine probiert?
Ja… an dem Rechner in der Berufsakademie war das gleiche Problem. So ein Mist, das muss laufen, ich krieg da ja ne Note dafür
ich denke dass es an dem repaint Aufruf liegt. Dieser wird zu oft aufgerufen und dann blockiert wahrscheinlich irgendeine Semaphore.
Versuch doch mal folgendes.
In Deiner paint-Methode gibt es es globales Flag, welches angibt, ob die paint-Methode komplett abgearbeitet wurde.
Ist dem nicht so (und die paint-Methode wird asynchron noch einmal aufgerufen), dann wird gar nichts gemacht (denn es muss ja ein alter Stand erst noch gezeichnet werden).
Problem hierbei, das die Synchronisation zwischen Slidern und Darstellung evtl. nicht übereinstimmt.
Das kann man aber auch in den Griff kriegen, denn Du kannst durch einfache Möglichkeiten herausbekommen ob ein Zeichenvorgang abgebrochen wurde, oder nicht.
Gruss,
Frank
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
ich denke dass es an dem repaint Aufruf liegt. Dieser wird zu
oft aufgerufen und dann blockiert wahrscheinlich irgendeine
Semaphore.
Versuch doch mal folgendes.
In Deiner paint-Methode gibt es es globales Flag, welches
angibt, ob die paint-Methode komplett abgearbeitet wurde.
Ist dem nicht so (und die paint-Methode wird asynchron noch
einmal aufgerufen), dann wird gar nichts gemacht (denn es muss
ja ein alter Stand erst noch gezeichnet werden).
Problem hierbei, das die Synchronisation zwischen Slidern und
Darstellung evtl. nicht übereinstimmt.
Das kann man aber auch in den Griff kriegen, denn Du kannst
durch einfache Möglichkeiten herausbekommen ob ein
Zeichenvorgang abgebrochen wurde, oder nicht.
Gruss,
Frank
Sorry ganz vergessen zu sagen, das hatte ich schon ausprobiert… hilft leider auch nicht.
Ich hab echt keine Ahnung mehr irgendwie lässt sich der Fehler absolut nicht sinnvoll reproduzieren.
Aber er tritt andauernd auf.
passiert das Neurechnen des nächsten Bildes in der Event-Methode ? Falls ja, dann würde ich das so machen, dass der Scrollbar-Event nur noch seinen „Verschieben-Wunsch“ irgendwo ablegt, und einen zweiten Thread per notifyAll informiert, dass neue Daten da sind. Der zweite Thread kümmert sich allen um das Neurechnen, und nimmt erst wieder Kommandos entgegen, wenn er mit einem Bild fertig ist. Warten keine Kommandos, dann legt er sich mit wait schlafen. So wird dann wahrscheinlich nichts mehr festklemmen.
Nachtrag
Erstaunliches Ergebnis:
Lasse ich das ganze Ding mit JDK1.4 beta 3 abspielen, dann bleibt nichts hängen und ich erhalte zusätzlich noch einen Performanceschub in der Grafikdarstellung um den Faktor 5 herum…
leider wird das natürlich nicht vom JBuilder unterstützt mit dem ich meine Java Anwendungen erstelle.
Sorry ganz vergessen zu sagen, das hatte ich schon
ausprobiert… hilft leider auch nicht.
Ich hab echt keine Ahnung mehr irgendwie lässt sich der Fehler
absolut nicht sinnvoll reproduzieren.
Aber er tritt andauernd auf.
kanns sein dass deine event-Handler nicht „synchronized“ sind ?
wenn nämlich viele Events in dem Handler ankommen und dieser sehr komplex ist, also Zeit braucht, kanns sein dass >1 Thread im Handler unterwegs sind… das kann „unangenehme“ Folgen haben (ist mir mit 1.3.0 passiert, trat in 1.4.0 beta 3 nicht auf).
Andererseits kanns auch sein dass die Native-Methode das gleiche Problem hat und bei „doppel“ Ausführung hängenbleidt.
Ich wiess dass das alles laut JVM-spec. nicht möglich ist, aber dem 1.3.0 trau ich in dem Punkt nicht mehr.
