Framebuffer

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+) Begründung: Der Artikel beschreibt nicht, was ein frame buffer wirklich ist und wie er funktioniert. Stattdessen werden Details über verschiedene Grafikmodi erklärt, aber nicht der frame buffer selbst. Siehe auch Diskussion:Framebuffer#Was ist ein frame buffer? --‣Andreas•⚖ 22:37, 18. Dez. 2021 (CET)

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.

Speicherbedarf

Die minimal benötigte Größe des Framebuffers ist abhängig von zwei Faktoren: der verwendeten Farbtiefe (genauer: Pixelformat) und der verwendeten Bildauflösung.

Farbtiefe

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.

• 1 Bit pro Pixel, zwei Farben (normalerweise hell und dunkel bei einem Monochrom-Monitor)
  • MDA
• 2 Bit pro Pixel, vier Farben
  • CGA: Palette mit 4 Farben aus 16 möglichen
• 4 Bit pro Pixel, 16 Farben
  • EGA: Palette mit 16 Farben aus 64 möglichen
• 8 Bit pro Pixel, 256 Farben
  • VGA: Palette mit 256 Farben aus 262144 möglichen
• 15 Bit pro Pixel, 32768 Farben
  • Real Color: Pixelformat 5-5-5, d. h. 5 Bit pro Farbkanal (also 32 Intensitätsabstufungen pro Kanal)
• 16 Bit pro Pixel, 65536 Farben
  • High Color: Pixelformat 5-6-5, d. h. 5 Bit für Rot und Blau (32 Intensitätsabstufungen) und 6 Bit für Grün (64 Intensitätsabstufungen)
  • alternativ auch 4-4-4-4, d. h. 4 Bit pro Farbkanal (16 Intensitätsabstufungen), wobei die letzten vier Bits entweder ungenutzt sind oder als Alphakanal verwendet werden (s. 32 Bit True Color)
• 24 Bit pro Pixel: 16777216 Farben
  • True Color: Pixelformat 8-8-8, d. h. 8 Bit pro Farbkanal (256 Intensitätsabstufungen)
• 32 Bit pro Pixel
  • True Color: Pixelformat 8-8-8-8, d. h. 8 Bit pro Farbkanal (256 Intensitätsabstufungen)
  • 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.

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.

• 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 und 255 oder als Festkommawert zwischen 0.0 und 1.0 $\left({\frac {\text{Wert}}{255}}\right)$ 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. Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 10^{12} : 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, 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

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

Auflösung (in Pixel)	Pixel- anzahl	Seiten- verhältnis
320 × 200	0.064.000	16:10
640 × 200	0.128.000	32:10a
640 × 480	0.307.200	4:3
800 × 600	0.480.000	4:3
1024 × 7680	0.786.432	4:3
1280 × 1024	1.310.720	5:4
1440 × 9000	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

^a bei üblichen 4:3-Bildschirmen meist anamorph als 16:10 dargestellt

Beispiele

• Textmodus (z. B. beim Hochfahren eines IBM-kompatiblen PCs mit BIOS)
  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.
• EFI-Framebuffer bei modernen PCs mit Unified Extensible Firmware Interface (UEFI)
  Bei EFI 1.x war mit
  Universal Graphics Adapter
  (UGA) ein von der Hardware unabhängiger EFI-Treiber verfügbar, um einen einfachen Video-Framebuffer zu nutzen. Dieser wurde mit UEFI 2.x durch das
  Graphics Output Protocol
  (GOP) ersetzt, das nun auch den Textmodus unabhängig von der Grafikkarte nutzen kann. Sowohl UGA als auch GOP ersetzt das Video-BIOS (kurz VBIOS, nur auf PCs mit BIOS) vollständig – VBIOS-Funktionen sind somit auch vom Grafiktreiber nicht mehr nutzbar, sodass einige ältere PC-Grafiktreiber unter (U)EFI bei identischer Hardware nicht funktionieren, bei aktiviertem CSM (der BIOS-Emulation von EFI bzw. UEFI) jedoch schon. Betriebssysteme und Gerätetreiber müssen daher EFI-UGA oder -GOP nutzen, um den Text- (bei GOP) oder Videomodus und weitere Firmware-Framebuffer-Funktionen nutzen zu können. Unter Linux existiert mit efifb ein generischer Framebuffer-Grafiktreiber, der auf allen EFI-PCs, und daher auch unabhängig von der spezifischen Grafikkarte, funktioniert. Auch Windows und macOS nutzen den EFI-Framebuffer, da er jedoch nur ohne Grafikbeschleunigung zur Verfügung steht, nur in einem eingeschränkten Modus.
• Grafikmodus (z. B. unter Windows oder beim X Window System unter Unix)
  Bei einer Bildschirmauflösung von 1024 × 768 Pixel und einer Farbtiefe von 24 Bit belegt der Framebuffer 1024 × 768 × 24 = 18874368 Bit = 2,25 MiB.

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

^* hier: 1 KB = 1024 Byte und 1kB = 1000 Byte

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

Knoppix booting Screenshot

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:

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 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;
}

Siehe auch

• DirectFB, Direct frame buffer, eine auf dem Linux frame buffer aufsetzende Programmbibliothek