java.awt.Component und paint()

[Sengha]

Mal ganz allgemein gefragt:

Gibt es neben BufferedImage noch andere Möglichkeiten, um Bilder in ein java.awt.Component-Objekt (z.B. JFrame oder JPanel) zu zeichnen? Also sozusagen direkt auf den Zielbuffer zuzugreifen und Farbinformationen dort ablegen? Ist sowas prinzipiell möglich? Braucht man dafür evtl. eine eigene Implementation eines "Graphics"-Objekts?

 

[Marco13]

Klingt sehr abstrakt. Du meinst aber nicht einfach ein überschreiben der paintComponent-Methode, oder?

class FreakyPanel extends JPanel
{
    public void paintComponent(Graphics g)
    {
        super.paintComponent(g);
        g.drawString("Woo-hooo.... nuuurse!", 30, 40);
    }
}

 

[Sengha]

nein, das meine ich nicht...

sagen wir einfach ich habe ein selbstentwickeltes bildobjekt mit bildspeicher, breite, höhe, usw. das ganze wird via jni aus einer c++ dll geholt. nun könnte ich natürlich eine konvertierung in ein buffered image durchführen. lieber wäre mir allerdings, ich könnte diesen bildspeicher direkt in ein jpanel malen (und zur anzeige bringen). ohne konvertierung. dazu bräuchte ich natürlich zugriff auf den bildspeicher des jpanel. man findet leider nicht sehr viel dazu im netz. daher die frage, ob sowas möglich ist. jeden pixel einzeln malen mithilfe des graphics-objekt ist auch nicht so der hit.

 

[Marco13]

jeden pixel einzeln malen mithilfe des graphics-objekt ist auch nicht so der hit.
Ja, sicher :lol: Ne, eine (direkte) effizientere Möglichkeit als ein BufferedImage wüßte ich nicht. Man könnte noch ein bißchen mit einer MemoryImageSource rumexperimentieren, aber BufferedImages werden "unter der Haube" sogar hardwarebeschleunigt - alles, was man dort "Per Hand" selbst implementieren könnte, um das ganze letztendlich auf den Bildschirm zu bringen, wäre vermutlich langsamer. Den einzigen Ansatzpunkt für Beschleunigungen würde ich jetzt darin sehen, dass man einen effizienten Weg findet, die "Rohdaten" in ein BufferedImage umzuwandeln. Da kann man (je nach Format der Rohdaten) ein bißchen was dengeln. (Ich nehme an, dass es in erster Linie um Performance geht, und nicht um den benötigten Speicher o.ä. !?). Fehlender direkter Zugiff auf (irgendeinen) "Bildspeicher" ist eben der Preis dafür, dass das ganze dann noch Plattformunabhängig ist... bzw. WÄRE: Wenn du sowieso JNI verwendest, besteht gundsätzlich die Möglichkeit, das ganze nativ von C aus (in einen Canvas) reinzumalen ... kann zwar gerade nicht aus dem Ärmel schütteln, wie genau das geht, aber da findet man im Netzt sicher was dazu. Falls das eine Option für dich ist.

 

[Wildcard]

Rohdaten direkt in den Videospeicher zu schreiben wird schwierig. Primär stehen dir als alternative Zeichenmethoden VolatileImages (Hardwarebeschleunigte Bilder im Grafikkartenspeicher) und Page Flipping (Verschieben des Memory Pointers der Graka) zur Verfügung.