- Bildwiederholspeicher
-
Der Bildspeicher bzw. Framebuffer (engl. frame – Einzelbild, buffer – Puffer) ist Teil des Video-RAM von Computern und entspricht einer digitalen Kopie des Monitorbildes. Das heißt, jedem Bildschirmpixel kann genau ein bestimmter Bereich des Framebuffers zugewiesen werden, der dessen digital übersetzten Farbwert enthält. Seit den 90er-Jahren befindet sich der Framebuffer vorwiegend auf der Grafikkarte.
Inhaltsverzeichnis
Speicherbedarf
Die Größe des Framebuffers ist abhängig von zwei Faktoren: die verwendete Farbtiefe (genauer: Pixelformat) und die verwendete Bildauflösung.
Farbtiefe
Die Farbtiefe des Framebuffers definiert die Maximalzahl der gleichzeitig auf dem Bildschirm angezeigten Farben. Die angegebenen Pixelformate geben an, wie viele Bits pro Pixel auf die einzelnen Farbkanäle (rot, grün, blau, alpha) vergeben wird - bei Farbmodi, die Paletten benutzen, fehlt diese Angabe, weil sie keinen Sinn ergibt.
- 1 Bit pro Pixel
- MDA
- zwei Farben
- 2 Bit pro Pixel
- CGA
- vier Farben aus einer Palette mit 16 Farben
- 4 Bit pro Pixel
- EGA
- 16 Farben aus einer Palette mit 64 Farben
- 8 Bit pro Pixel
- VGA
- 256 Farben aus einer Palette mit 262144 Farben
- 15 Bit pro Pixel
- Real Color
- 32768 Farben
- Pixelformat 5-5-5, d. h. 5 Bit pro Farbkanal (also 32 Farbabstufungen pro Kanal)
- 16 Bit pro Pixel
- High Color
- 65536 Farben
- Pixelformat 5-6-5, d. h. 5 Bit für Rot und Blau (32 Farbabstufungen) und 6 Bit für Grün (64 Farbabstufungen)
- alternativ auch 4-4-4-4, d. h. 4 Bit pro Farbkanal (16 Farbabstufungen), wobei die letzten vier Bits entweder ungenutzt sind oder als Alphakanal verwendet werden (s. 32 Bit True Color)
- 24 Bit pro Pixel
- True Color
- 16777216 Farben
- Pixelformat 8-8-8, d. h. 8 Bit pro Farbkanal (256 Farbabstufungen)
- 32 Bit pro Pixel
- True Color
- Pixelformat 8-8-8-8, d. h. 8 Bit pro Farbkanal (256 Farbabstufungen)
- Die gegenüber 24 Bit True Color hinzugekommenen 8 Bit werden normalerweise nicht genutzt; auf Rechnern mit 32-Bit-Architektur ist die Verarbeitung von 32-Bit-Werten aber effizienter als die von 24-Bit-Werten, weil dies genau der Wortbreite des Prozessors entspricht, weswegen trotz des 33% höheren Speicherbedarfs True-Color-Framebuffer meistens 32 Bit Farbtiefe benutzen.
In der 3D-Computergrafik werden auch Framebuffer mit höherer Genauigkeit benutzt. Dort benötigt die Bestimmung der Farbe eines Pixels oftmals mehrere Rechenschritte, wobei bei jedem Zwischenergebnis Rundungsfehler entstehen können, die bei herkömmlichen Framebufferformaten schnell sichtbar sind und störend wirken.
Bei diesen genaueren Formaten interpretiert man die Farbkanalwerte als Kommawerte auf einer Skala von 0.0 bis 1.0, damit bei der Verwendung mehrerer Pixelformate die Handhabung vereinfacht wird.
- FX8
- pro Farbkanal 8 Bit Festkomma, somit 256 Farbabstufungen linear skaliert
- identisch mit oben genannten 32 Bit pro Pixel. Ob man die 256 verschiedenen Werte pro Farbkanal als ganze Zahl zwischen 0 bis 255 oder als Festkommawert zwischen 0.0 und 1.0 () auffasst, ist lediglich Interpretationssache.
- maximaler Kontrast 255:1, daher geeignet für Low Dynamic Range (LDR) Rendering, wie es gewöhnliche Bildschirme aller Art anzeigen können
- FX12
- pro Farbkanal 12 Bit Festkomma, somit 4096 Farbabstufungen linear skaliert
- höhere Genauigkeit als FX8
- maximaler Kontrast 4095:1, geeignet für Low Dynamic Range (LDR) Rendering
- FX16
- pro Farbkanal 16 Bit Festkomma, somit 65536 Farbabstufungen linear skaliert
- höhere Genauigkeit als FX12
- maximaler Kontrast 65535:1, geeignet für Medium Dynamic Range (MDR) Rendering
- FP16
- pro Farbkanal 16 Bit Gleitkomma (davon 5 Bit Exponent und 10 Bit Mantisse), somit 32768 Farbabstufungen exponentiell skaliert
- Die exponentielle Skala erlaubt im Vergleich zu FX16 eine wesentlich feinere Auflösung bei kleinen Werten, bei größeren Werten ist es aber ungenauer.
- maximaler Kontrast ca. 1012:1, geeignet für High Dynamic Range (HDR) Rendering.
- FP24
- pro Farbkanal 24 Bit Gleitkomma (davon 7 Bit Exponent und 16 Bit Mantisse), somit mehr als 8 Mio. Farbabstufungen exponentiell skaliert
- höhere Genauigkeit als FP16 (max. Kontrast ca. 1043:1), daher sehr gut geeignet für HDR-Rendering
- FP32
- pro Farbkanal 32 Bit Gleitkomma (davon 8 Bit Exponent und 23 Bit Mantisse), somit mehr als 2 Mrd. Farbabstufungen exponentiell skaliert
- noch höhere Genauigkeit als FP24 (max. Kontrast ca. 1083:1)
Bildauflösung
Die Bildauflösung gibt an, aus wie vielen Pixeln der Framebuffer besteht. Üblicherweise gibt man hierbei die horizontale und vertikale Pixelanzahl an, wodurch man auch das Seitenverhältnis direkt berechnen kann, üblich sind hier 4:3, 5:4 und 16:10.
Typische Framebuffer-Auflösung:
- 640 × 480: 307200 Pixel, Seitenverhältnis 4:3
- 800 × 600: 480000 Pixel, Seitenverhältnis 4:3
- 1024 × 768: 786432 Pixel, Seitenverhältnis 4:3
- 1280 × 1024: 1,31 Mio. Pixel, Seitenverhältnis 5:4
- 1680 × 1050: 1,76 Mio. Pixel, Seitenverhältnis 16:10
- 1600 × 1200: 1,92 Mio. Pixel, Seitenverhältnis 4:3
- 1920 × 1200: 2,3 Mio. Pixel, Seitenverhältnis 16:10
- 2048 × 1536: 3,15 Mio. Pixel, Seitenverhältnis 4:3
- 2560 × 1600: 4,10 Mio. Pixel, Seitenverhältnis 16:10
Beispiele
- Textmodus (z. B. beim Hochfahren eines IBM-kompatiblen PCs oder im Konsolenmodus unter Linux)
Bei einer 80 × 25 Zeichen großen Konsole, wobei jedes Zeichen und seine Farbe mit jeweils 8 Bit (also zusammen 16 Bit) gespeichert wird, belegt der Framebuffer 80 × 25 × 16 = 32000 Bit = 4 KB. - Grafikmodus (z. B. unter Microsoft Windows oder beim X Window System unter Linux)
Bei einer Bildschirmauflösung von 1024 x 768 Pixel und einer Farbtiefe von 24 Bit belegt der Framebuffer 1024 × 768 × 24 = 18874368 Bit = 2,25 MB.
Breite × Höhe × Farben Speicherbedarf[1] Standard 320 × 200 × 2 ≈ 8 KB
(8 kB)C64 640 × 200 × 2 ≈ 16 KB
(16 kB)CGA 750 × 350 × 2 ≈ 32 KB Hercules 640 × 350 × 16 ≈ 109 KB
(112 kB)EGA 640 × 480 × 16 150 KB VGA 320 × 200 × 256 62,5 KB
(64 kB)VGA 640 × 480 × 256 300 KB VGA-extended 800 × 600 × 256 468,75 KB
(480 kB)SVGA 1024 × 768 × 256 768 KB XGA 1024 × 768 × 64k 1,5 MB XGA 1024 × 768 × TrueColor 2,25 MB XGA 1280 × 960 × TrueColor ≈ 3,5 MB SXGA 1400 × 1050 × TrueColor ≈ 4,2 MB SXGA+ 1600 × 1200 × TrueColor ≈ 5,5 MB UXGA 1920 × 1200 × TrueColor ≈ 6,6 MB WUXGA 2048 × 1536 × TrueColor 9 MB SUXGA 2560 × 960 × TrueColor ≈ 7 MB Dual SXGA 2560 × 1600 × TrueColor ≈ 12 MB QWXGA/WQXGA In der Übersicht wurde im Fall von TrueColor berücksichtigt, dass Daten intern mit 24 Bit gespeichert werden.
Verbesserungen
Durch Unzulänglichkeiten in der Kontinuität der Bildfolge, und um die allgemeine Darstellungsqualität weiter zu erhöhen, wurde das Konzept des Framebuffers im Laufe der Zeit überarbeitet. So entspricht ein Framebuffer auf aktuellen Systemen mehreren Pufferspeichern.
- Bei der Doppelpufferung (double buffering) wird der Framebuffer in zwei Bereiche (Frontbuffer und Backbuffer) unterteilt.
- Bei der Dreifachpufferung (triple buffering) wird der Framebuffer in drei Bereiche (1 Frontbuffer und 2 Backbuffer) unterteilt.
Linux-Framebuffer
Das Linux Framebuffer Device (kurz fbdev) ist eine hardwareunabhängige Abstraktionsschicht unter Linux, um Grafiken auf der Konsole bzw. mit X-Window (xf86_fbdev) anzuzeigen. Dabei setzt das Framebuffer-Device nicht auf systemspezifischen Bibliotheken wie der SVGALib oder dem X Window System auf und ist somit eine ressourcensparende Alternative zum weiterverbreiten X-Server, auf dem heute die meisten grafischen Oberflächen für Linux aufbauen. Es ist seit der Linux-Kernelversion 2.1.107 für alle Plattformen im Standardkernel enthalten.
Ursprünglich wurde es für Linux/m68k implementiert, um auf entsprechenden Systemen (Amiga, Atari, Macintosh) mit einer geringen Hardwarebeschleunigung eine Textkonsole zu emulieren und wurde erst später auf die IBM-PC-kompatible Plattform erweitert.
Heutzutage kann der Framebuffer direkt von verschiedenen Programmen wie MPlayer und Bibliotheken wie GGI, SDL, GTK+ und Qt Extended benutzt werden. Das ressourcensparende Konzept macht den Einsatz besonders für eingebettete Systeme interessant.
Insbesondere wird es von verschiedenen Betriebssystemen (Ubuntu, openSUSE) verwendet, um schon während des Bootstrapping in Form eines Splash Screens eine grafische Ausgabe zu ermöglichen.
Der am häufigsten verwendete VESA-Framebuffer-Treiber (vesafb) baut auf einheitlichen Spezifikationen von Videostandards auf und erlaubt so einen Zugriff auf Grafikkarten größtenteils unabhängig vom Hersteller. Dadurch ist dann auch eine quelloffene Implementation möglich. Außerdem wurden von diversen Grafikchipherstellern (Nvidia: rivafb, nvidiafb; AMD: radeonfb) proprietäre Treiber auf den Markt gebracht.
Bekannt wurde das Framebuffer-Device durch die Möglichkeit, während des Linux-Kernel-Ladevorgangs dem Benutzer ein Tux-Logo anzuzeigen. Dazu muss es aber zunächst im Kernel enthalten sein und beim nächsten Reboot durch den Boot-Loader, der auch das Betriebssystem in den Arbeitsspeicher lädt, durch die Angabe des Paramenters
video
aktiviert werden.Im Folgenden werden zwei Beispiele gezeigt, indem ein AMD-Treiber mit einer Bildauflösung von 1024×768 Bildpunkten bei einer Farbtiefe von 8 Bit pro Pixel und einer Bildwiederholungsfrequenz von 76 Hz geladen wird:
- Beispiel für eine LILO Konfigurationsdatei
# LILO configuration file boot = /dev/sda1 # Linux bootable partition config begins image = /vmlinuz append = "video=atyfb:1024x768-8@76,font:SUN8x16"
- Beispiel für eine GRUB Konfigurationsdatei
# GRUB configuration file # For booting LINUX title Linux kernel (hd0, 0) /vmlinuz video=atyfb:1024x768-8@76,font:SUN8x16 root=/dev/hda1
Für einen Hardwarezugriff auf das Framebuffer-Device muss nicht unbedingt ein Kernelmodul geschrieben werden. Ferner hat die Anwendung die Möglichkeit im User-Mode über die Gerätedatei
/dev/fb*
auf das Device zuzugreifen und in den Grafikspeicher zu schreiben. In folgendem Beispiel wird demonstriert, wie mit der Programmiersprache C linear in den Framebuffer geschrieben werden kann. Hier wird der hexadezimale Wert 0x01 (Binär: 0b00000001) für jedes Pixel gesetzt:#include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> #include <sys/ioctl.h> #include <fcntl.h> #include <linux/fb.h> #include <unistd.h> int main(int argc, char **argv) { int row, col, width, height; unsigned char *data; // Oeffnen des Geraetes int fd = open("/dev/fb0", O_RDWR); // Informationen ueber den Framebuffer einholen struct fb_var_screeninfo screeninfo; ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo); if(screeninfo.bits_per_pixel != 8) return 0; width = screeninfo.xres; height = screeninfo.yres; // Zeiger auf den Framebufferspeicher anfordern data = (unsigned char*) mmap(0, width * height, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); // in den Framebuffer-Speicher schreiben. Hier wird Pixel fuer Pixel auf // die Farbe 0x01 gesetzt for(row = 0; row < height; row++) for(col = 0; col < width; col++) data[row * width + col] = 0x01; // Zeiger wieder freigeben munmap(data, width * height); }
Referenzen
- ↑ hier: 1 KB = 1024 Byte und 1kB = 1000 Byte
- 1 Bit pro Pixel
Wikimedia Foundation.