Graphics2D Grafikkarte

Sonstiges Software
1

Hallo zusammen!
Inwiefern benutzt/benötigt Graphics2D die Grafikkarte eines Computers, wenn die Zeichnungen auf eine BufferedImage ausgeführt werden?

Alles wird nur auf einer BufferedImage gemalt, es muss nichts auf den Bildschirm “gezeichnet” werden.

2

wie tief geht denn deine Frage, brauchst du genaue wissenschaftliche Ausarbeitungen oder fragst du nur aus Interesse?

pauschal behauptet ist alles in 2D-Swing (und wohl auch sonstige normale Fenster-Programme, Bildbetrachter und -bearbeitung) pixelbasiert,
Berechnungen erfolgen programmintern, Speicherung usw. kann alles für sich bleiben,

wenn ein Monitor und graphisches Betriebssystem dabei ist kann man das zwischendurch gerne mal anzeigen, aber das ist simples Durchleiten der Daten,
keine echte Herausforderung für eine Grafikkarte, vielleicht Skalierung auf bestimmte Bildschirmgrößen,
man kann auch die Highend-‚Grafikkarte‘ ausbauen und auf dem Mainboard ist sicher genug primitives vorhanden für simple Anzeigen im paar Mio. Farben

das merkt man auch in Swing nicht sonderlich, nicht in den oberen Java-Klassen, deren Quellcode man anschauen kann,
sondern die native Weiterleitung ans Betriebssystem bewirkt etwas oder auch nicht,

wirkliche Arbeit für Grafikkarten ist nur 3D-Rendern,
wenn das Programm nichts über bestimmte Pixel weiß sondern nur abstrakte Informationen über Raum und Oberflächentexturen liefert

aber alles wirklich ohne Gewähr :wink:
hätte ich nicht noch nebenher Hinweis auf Umbenennung und Verschiebung weg von Java Basics zu posten, hätte ich vielleicht gar nicht erst spekuliert,
bitte darauf achten was Java Basics sind und was nicht, da geht es um die Sprache, wenn überhaupt dann noch eine Swing-Frage

3

Ich denke das ganze wird komplett auf der CPU berechnet.

OT: @SlaterB , wieso benutzt du eigentlich keine Punkte? :smiley:

4

benutze ich immer wenn mal nötig: sogar auch zwei auf einmal

5

Ich weiss das zwar auch net, aber für solche Fragen ist der Java Troubleshooting Guide oftmals hilfreich:

**§3.1
Java 2D uses a set of pipelines, which can be roughly defined as different ways of rendering the primitives. These pipelines are as follows:

  • X11 pipeline, which is the default for Solaris OS and Linux
  • OpenGL pipeline, which is an alternative on Solaris OS and Linux, as well as Windows
  • DirectDraw/GDI pipeline, which is the default on Windows
  • Direct3D pipeline, which is an alternative on Windows
    By choosing a different pipeline, or manipulating the properties of a pipeline, you might be able to determine the cause of the problem, and often find a workaround.

§3.2.1
In general, hardware accelerated rendering could be divided into two categories.

  • Hardware-accelerated rendering to an “accelerated” destination. Examples of rendering destinations which can be hardware-accelerated are VolatileImage, screen, and BufferStrategy. If a destination is accelerated, rendering which goes to such surface may be performed by video hardware. So if you issue a drawRect call, Java 2D redirects this call to the underlying native API (such as GDI, DirectDraw, Direct3D or OpenGL, or X11), which performs the operation using hardware.
  • Caching images in accelerated memory (Video memory or pixmaps) so that they can be copied very fast to another accelerated surface. Such images are known as “managed images.”**

Ich habe allerdings den Eindruck, das sich das alles nur auf Images bezieht, welche auf dem Bildschirm dargestellt werden (sollen), nicht jedoch auf BufferedImages. Vielleicht kann man da ja ein Volatile Image draus machen?

Vor einigen Jahren hatte ich mich zwangsweise mal damit auseinandersetzen müssen wie man Kreise effizient in ein BufferedImage zeichnet. Quintessenz war: fillRectangle ist schnell, fillOval ist schnarchlangsam. Was mich auch nicht weiter erstaunte, nachdem ich mir angesehen hatte wie ein Oval in ein BufferedImage gezeichnet wird… Selbst wenn es da am Ende noch eine Hardwareunterstützung gibt kann von Effizienz keine Rede sein.
Aber auch fillRectangle war (für 100.000 Rechtecke mit Kantenlängen bis 20 Pixeln) keinen Deut schneller als mein hingerotzter Software-Kreis-Renderer. Von daher möchte ich, wie meine Vorredner, vermuten, das an der Stelle keinerlei Unterstützung durch die Grafikkarte stattfindet.
In irgendeinem Blog hatte ich mal gelesen, das es für BufferedImages per se nur eine Art von Hardwarunterstützung gibt: Wenn ein BufferedImage zum dritten Mal unverändert(!) auf dem Bildschirm dargestellt wird, dann wird es in den Speicher der Grafikkarte kopiert. Und das war auch alles. Keine Ahnung ob das stimmt, aber plausibel scheint’s mir schon zu sein.

6

Da eine “fundierte”, belegbare Aussage zu machen ist schwierig, solange man sich nicht auf den OpenJDK-Quellcode bezieht. Die Tatsache, dass man auch Dinge in ein BufferedImage reinmalen kann, wenn im PC gar keine Grafikkarte steckt, suggeriert eine Antwort auf die Frage, aber nach all dem, was ich bisher in den privaten Sun-Klassen und dem OpenJDK gesehen habe, gibt’s nur zwei Dinge, die ich mit Sicherheit sagen kann: 1. Das ganze ist ziemlich kompliziert, und 2. Ich weiß, dass ich nicht(s) weiß …