Hallo,

ich bräuchte ein paar Denkanstösse, wie ich folgendes Problem lösen könnte:

Ziel ist die Ausgabe einzelner Pixel (max. 640*480) auf ein JFrame.

Die Daten, sprich die einzelnen RGB-Farbwerte hole ich aus einer Map. Diese ändern sich dann natürlich auch zur Laufzeit.

Mein Problem ist nun, wie ich es schaffe dass möglichst effizient in einem JFrame ein einzelner pixel einen bestimmten Farbwert enthält.

Bis jetzt habe ich das z.B. über ein BufferedImage versucht, das in einem JLabel bzw. ImageIcon gesteckt hat. Dann habe ich für jeden pixel, der sich ändert, die Methode bi.setRGB(x,y,newRGB) aufgerufen und das frame neu gepaintet. Diese Methode ist aber relativ langsam. Ich wollte nun fragen ob jmd einen anderen Vorschlag hat wie ich da rangehen könnte. Wie gesagt, Ziel ist einfach bestimmte pixel neu einzufärben.

Ich denke nicht, dass man hier pauschal sagen kann, was man verbessern könnte. Vielleicht schilderst Du einmal das komplette Problem, weil wenn es z.B. in die Richtung Computergraphik geht, dann wären andere Algorithmen sinnvoller

HTH

Phil

Hmm ok ich will mal versuchen es zu umschreiben....

es geht um die VGA-Schnittstelle eines FPGA-Boards, auf dem ein selbstentwickelter Mikroprozessors "implementiert" ist. Für diesen soll ein Simulator geschrieben werden. Im Assembler-Code werden nun also die entsprechenden Bitkombinationen in einen speziellen Speicherbereich geschrieben. Dieser wird im Simulator durch eine Map repräsentiert. Bei jedem Schreibzugriff auf diesen Bereich wird eine Methode des VGA-Moduls aufgerufen. In dieser soll nun eben der entsprechende Pixel auf der Anzeige gesetzt werden. Position des Pixels und Hexwerts werden aufgrund der Zieladresse bzw. des Bitmusters vorher schon bestimmt. Es geht also im Prinzip nur noch darum, den Pixel an Pos x,y mit Farbe rgb zu setzen. Ansonsten ist im Simulator alles fertig, auch die Anzeige funktioniert prinzipiell schon (über BufferedImage), nur wollte ich eben wissen wie man das noch beschleunigen könnte.

Bearbeitet 23. Juni 200916 j von blubbla

Was heißt denn relativ langsam?

Ohne Hardwareunterstützung wirst Du nie mehr als 10-30fps erreichen.

Eine Möglichkeit wäre noch, das ganze nicht mit einem BufferedImage zu machen, sondern direkt auf z.Bsp. auf ein eigens abgeleitetes JPanel zu zeichnen und dieses Panel.setDoubleBuffered(true).

Die methode mit dem BufferedImage ist eigentlich eine der besten. Da kannst du einzelne Pixel - wie du schon gesagt hast - über setRGB ändern oder normal mit dem Graphics/Graphics2D-Objekt zeichen.

Habe auch schon GIS-Anwendungen geschrieben und bin da ähnlich rangegangen. Selbst das umwandeln von Höhendaten in anzeigbare Bilder war mit der setRGB-Methode kein größes Problem.

Der Vorteil beim Verwenden von Bildern ist eben auch der, dass du nicht jedes mal alles neu zeichnen musst, nur weil der User grad ein anderes Fenster über eine Anwendung schiebt.

Wo genau tritt denn das Problem auf, dass es zu lange dauert? Das einfärben von ein paar Pixeln dürfte eigentlich nicht all zu lang dauern. Es sei denn du arbeitest mit extrem hochauflösenden Images. Das Image sollte generell nicht größer sein, als wie du es benötigst (imageSite = SizeOfViewField)

Es ist auch immer die Frage wie Du die Daten vorhälst bzw setzt. Evtl kannst Du durch effiziente Datenstrukturen auch nur die Pixel setzen, die Du benötigst bzw. Du setzt nur die Pixel die sich verändert haben anstatt des gesamten Bildes.

Ich denke der Ansatz recht umfassend. Wenn es Dir wirklich um Geschwindigkeit geht, dann würde ich Dir wirklich zu externen Komponenten raten Jogl ? Wikipedia

Indem Du die komplette Graphikroutinen extern machen lässt und nur die Daten hinein gibst

Phil

P.S.: Und mit OpenGL kann man auch 2D arbeiten, wenn man die Matrizen zur Projektion entsprechend wählt

Also ich hab in der Mittagspause mal ne kleine Demo gemacht.

Dabei werden in einer Endlosschleife (ohne Thread.sleep) in jedem Durchlauf alle Pixel in einem 640x480-RGB-BufferedImage per Random gesetzt und dann das Bild auf einen Frame gezeichnet.

Dabei komm ich mit Math.round(Math.random()) bei meinem Laptop auf 13fps.

Ohne die beiden Math-Methoden, also, wenn die Pixelfarbe vorher schon feststeht ist das bei 30fps.

Meine erste Alternative mit dem "direkt aufs JPanel" kannst ganz getrost in die Ecke knallen *schäm*. Die taugt nämlich nichtmal ansatzweise.

Aber mit 30fps könnte ich prima leben auf meinem Core2Duo T8100.

Habs dann nochmal mit nem direktschreiben per WriteableRaster probiert, aber ist nicht signifikant schneller, nur etwa 10%.

Vielleicht generell zum Thema: Meist liegt das Problem nicht beim eigentlichen Paint, sondern oft in anderen Bereichen. Du müsstest ein Profiling machen, um ggf herauszufinden welche Codeteile langsamer bzw schneller sind

Phil