Der Framebuffer oder Bildspeicher (englisch frame – Einzelbild, buffer – Zwischenspeicher) ist Teil des Grafikspeichers 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 1990er-Jahren befindet sich der Framebuffer vorwiegend auf der Grafikkarte.
Die minimal benötigte Größe des Framebuffers ist abhängig von zwei Faktoren: der verwendeten Farbtiefe (genauer: Pixelformat) und der verwendeten Bildauflösung.
Die Farbtiefe des Framebuffers definiert die Maximalzahl der gleichzeitig auf dem Bildschirm angezeigten Farben oder Farbnuancen. Im Bereich der IBM-PC-kompatiblen Computer waren und sind die in der folgenden Aufstellung angegebenen Größen üblich. Die angegebenen Pixelformate geben an, wie viele Bits pro Pixel auf die einzelnen Farbkanäle (rot, grün, blau, Alphakanal) vergeben werden – bei Farbmodi, die indizierte Farben (Paletten) benutzen, fehlt diese Angabe, weil sie keinen Sinn ergibt.
Bei Grafikhardware, die mit Bitplanes arbeitet (z. B. Amiga), sind bei indizierten Farben auch 3, 5, 6 und 7 Bit pro Pixel mit dementsprechend 8, 32, 64 bzw. 128 Farben üblich.
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.
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.
| Auflösung (in Pixel) |
Pixel- anzahl |
Seiten- verhältnis |
|---|---|---|
| 320 × 200 | 64.000 | 16:10 |
| 640 × 200 | 128.000 | 32:10a |
| 640 × 480 | 307.200 | 4:3 |
| 800 × 600 | 480.000 | 4:3 |
| 1024 × 768 | 786.432 | 4:3 |
| 1280 × 1024 | 1.310.720 | 5:4 |
| 1440 × 900 | 1.296.000 | 16:10 |
| 1680 × 1050 | 1.764.000 | 16:10 |
| 1600 × 1200 | 1.920.000 | 4:3 |
| 1920 × 1200 | 2.304.000 | 16:10 |
| 2048 × 1536 | 3.145.728 | 4:3 |
| 2560 × 1600 | 4.096.000 | 16:10 |
| Breite × Höhe × Farben | Speicherbedarf * | Standard |
|---|---|---|
| 320 × 200 × 2 | ≈ 8 KB (8 kB) |
C64 |
| 320 × 200 × 16 | ≈ 32 KB
(32 kB) |
Atari ST |
| 640 × 200 × 2 | ≈ 16 KB (16 kB) |
CGA |
| 750 × 350 × 2 | ≈ 32 KB | Hercules |
| 640 × 350 × 16 | ≈ 109 KB (112 kB) |
EGA |
| 640 x 400 x 1 | ≈ 32 KB
(32 kB) |
Atari ST |
| 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 | WQXGA |
In der Übersicht wurde im Fall von TrueColor berücksichtigt, dass Daten intern mit 24 Bit gespeichert werden.
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.
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 weiterverbreiteten 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 Linux68k implementiert, um auf entsprechenden Systemen (Amiga, Atari, Macintosh) mit einer geringen Hardwarebeschleunigung einen Textmodus 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 Distributionen (Ubuntu, openSUSE) verwendet, um schon während des Bootstrappings 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 Bootloader, der auch das Betriebssystem in den Arbeitsspeicher lädt, durch die Angabe des Parameters video aktiviert werden.
Im Folgenden werden zwei Beispiele gezeigt, in denen 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:
# LILO configuration file boot = /dev/sda1 # Linux bootable partition config begins image = /vmlinuz append = "video=atyfb:1024x768-8@76,font:SUN8x16"
# 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 0x000000FF (Binär: 0b00000000000000000000000011111111) 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>
#include <stdio.h>
int main(int argc, char **argv) {
int row, col, width, height, bitspp, bytespp;
unsigned int *data;
// Öffnen des Gerätes
int fd = open("/dev/fb0", O_RDWR);
// Informationen über den Framebuffer einholen
struct fb_var_screeninfo screeninfo;
ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo);
// Beende, wenn die Farbauflösung nicht 32 Bit pro Pixel entspricht
bitspp = screeninfo.bits_per_pixel;
if(bitspp != 32) {
// Ausgabe der Fehlermeldung
printf("Farbaufloesung = %i Bits pro Pixel\n", bitspp);
printf("Bitte aendern Sie die Farbtiefe auf 32 Bits pro Pixel\n");
close(fd);
return 1; // Für den Programmabbruch geben wir einen Rückgabetyp != 0 aus.
}
width = screeninfo.xres;
height = screeninfo.yres;
bytespp = bitspp/8; //Bytes pro Pixel berechnen
// Überprüfen ob der Typ unsigned int die gleiche Byte-Grösse wie ein Pixel besitzt.
// In unserem Fall 4 Byte (32 Bit), falls nicht wird das Programm beendet
if(sizeof(unsigned int) != bytespp) {
close(fd);
return 1;
}
// Zeiger auf den Framebufferspeicher anfordern
data = (unsigned int*) mmap(0, width * height * bytespp, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// In den Framebuffer-Speicher schreiben. Hier wird Pixel für Pixel auf
// die Farbe 0x000000FF (Blau) gesetzt, da ein Pixel das AARRGGBB Format hat
for(row = 0; row < height; row++)
for(col = 0; col < width; col++)
data[row * width + col] = 0xFF;
// Zeiger wieder freigeben
munmap(data, width * height * bytespp);
// Gerät schließen
close(fd);
// Rückgabewert
return 0;
}