Diskussion:Framebuffer

farbtiefe mehr als 32-bit

warum entwickeln hardwarehersteller keine grafikkarten mit mehr farbtiefe als 32-bit? ist es möglich auf aktuellen grafikkarten mehr farbtiefe zu erhalten durch veränderung der software? warum machen softwarehersteller das nicht? macht das alles sinn? wenn nein, warum? --77.189.124.147 12:10, 1. Apr. 2010 (CEST)

Weil Menschen so viele Farben ohnehin nicht unterschieden kann. Bei HDRR wird zwar mit mehr als 32bit gerendert, aber bevor das ganze dann in den Frameebuffer geschrieben wird, wirds auf 32bit runtergerechnet. Es gab aber mal Grafikkarten, die einen Modus unterstützten, bei dem die 32bit anders aufgeteilt waren (jeweils 10bit für jede Farbe + 2 bit für den Alpohakanal, anstatt jeweils 8 bit für jede Farbe und den Alphakanal), dieser Modus wurde jedoch kaum unterstützt und ist soviel ich weiß auch wieder vom Grafikkartenmarkt verschwunden. Natürlich könnte man mehr bits auch nutzen, um den Alphakanal zu vergrößern, bringt aber soviel ich weiß auch nichts, da das menshcliche Auge angeblich ohnehin nur ca. 60 Graustufen unterscheiden kann. Ich habs alllerdings in einem Selbstversuch mit dem Programm eizo-test 9 und auf möglcihst gute Erkennbarkeit veiieler Grauustufen optimierten Monitoreinstellung es geschafft, alle 256 Gaufstufen zu unterschieden (der Testbildschirm bestand aus einem Quadrat, das sich ind er Mitte des Bildschirms befindet und ca. die Hälfte der Bildschirmhöhe einnimmt, sowie einen Hintergrund und einem Regler, mit dem man die Farben für das Quadrat und den Hintergrund beliebig einstellen kann, ich hab den Bildschrima uf möglcihst guete Unterschiedbarkeit von garustufen optimeirt (hat keine 5 minuten gedauert) und dann folgendes verglichen, indem ich immer einen dieser 2 Werte fürs Rechteck und einen fürn hintergrund eingestellt hab und versucht hab, die Grenze zwischen rechteck und Hintergrund zu erkennen, was mir immer gelang. Ich hab folgende Werte probiert: 0/0/0-1/1/1, 254/254/254-255/255/255, sowie einige Zwischenwerte, wobei immer nur eine graustufe dazwischen war). Allerdinsg konnte ich bei Unterschieden von nur einer Graufstufe bis 6/6/6-7/7/7 nurmehr den Umriss des Rechtecks erkennen, aber nichtmehr, ob das Quadrat oder der Hintergrund heller ist, aber bei 0/0/0-2/2/2 war der Helligkeitsunterschied auch shcon duetlich. Also selbst wenn mand as als Bedingung nimmt, konnte ich mindestens 252 Graustufen unterscheiden, mit etwas optimierterer Bildschrimkalibration wären wahrscheinlcih alle 256 drin gewesen. Allerdings braucht amn da wirklich schon 2 sehr große Blöcke, bei echten Fotos oder Spielen kann man möglicherweise wirklich nur 60 Graustuifufen unterscheiden, selbst wenns schwarz-weiß-Fotos sind. --MrBurns 12:55, 1. Apr. 2010 (CEST)

Korrekte Übersetzung?

Ehrlich gesagt, ich bin gegen diese sinnlosen "Gewaltübersetzungen" noch dazu, wenn sie falsch sind, wie in diesem Beispiel: Der Framebuffer (deutsch: „Bildspeicher“) - frame (en) ist korrekterweise mit Rahmen oder Bilderrahmen zu übersetzen. Ich plädiere dafür, solche "Übesetzungen" nach Möglichkeit wegzulassen. - Ernèsto! 13:13, 31. Jan 2006 (CET)

Geht mir ähnlich, nur gibt es auch menschen, die dem englischen nicht mächtig sind. mir ist leider keine treffendere deutsche übersetzung zu framebuffer eingefallen, deswegen hatte ich es eher sinnvoll (hoffte ich jedenfalls) als wörtlich übersetzt. zu deinem vorschlag entsprechende übersetzungen in zukunft zu unterlassen, starte doch einfach mal ein meinungsbild. --Murkel ^(anmurkeln) 11:51, 1. Feb 2006 (CET)

Das wird kaum nötig sein. In Klammern kann ggf. auch eine wortwörtliche deutsche Übersetzung angegeben werden, die aber als solche auch erkennbar sein sollte. An sich kann man meines Erachtens den Framebuffer auch Rahmenpuffer nennen. Ich baue es mal ein. Entsprechende Google-Treffer gibt es auch. Ich baue es mal vorsichtig um. Stern 22:13, 1. Feb 2006 (CET)

Kann vllt mal jemand ergänzen, wofür es den Framebuffer überhaupt gibt? Meines Wissens nach handelt es sich dabei um einen speziellen dual-ported-Speicher, da man gleichzeitig lesen und schreiben muss, was wohl klar sein sollte. Das wurde aber nur mal kurz am Rande einer Vorlesung erwähnt...

Das steht bereits alles in der einleitung. der artikel beschreibt das konzept des framebuffers. für die hardwareseitige umsetzung - also den angesprochenen dual ported memory - siehe Video-RAM oder GDDR oder Halbleiterspeicher.

Der framebuffer ist nur ein bestimmter bereich des gesamten zur verfügung stehenden grafikspeichers. es ist also nicht möglich, einzelne auf der grafikkarte verbaute halbleiterspeicher dem framebuffer zuzuschreiben. wie es bereits im artikel steht, entspricht der framebuffer dem digital übersetzten monitorbild - nicht mehr und nicht weniger.

Gruß --Murkel ^(anmurkeln) 13:49, 3. Mai 2006 (CEST)

"Bilderrahmen"??? Sonst geht's noch? "Bildspeicher" ist der im Deutschen gebräuchlichste Begriff und eine völlig korrekte Übersetzung. Leider sind die Wortfelder nicht identisch, da Framebuffer hauptsächlich die Sicht des Programmierers beschreibt. Das stand sogar mal im Artikel drin, bevor irgendein Held das entsorgt hat. Wikipedia verseptembert immer mehr.

Ach ja, und "frame" heißt in diesem Kontext schlicht (Einzel)bild. Die einzelnen Bilder eines Videos heißen z.B. frame.

ich verstehe deine kritik leider nicht. bildspeicher wird doch korrekt per redirect auf die seite verlinkt. die übersetzung von frame dient nur der klärung der wortbestandteile des englischen framebuffer. es soll daraus also keine direkte deutsche übersetzung abgeleitet werden. (nebenbei für rahmenpuffer gibts fast 1000 google hits)

der von dir aufgeführte satz wurde entfernt, weil daraus einfach nichts abzuleiten ist. programmierer interessieren sich auch für andere teile der speicher- bzw. systemarchitektur, ohne das ein entsprechender verweis z.b. in hauptspeicher oder grafikprozessor zu finden ist. schliesslich ist das ja ihr aufgabengebiet, systemkomponenten zu programmieren.

gruß --Murkel ^(anmurkeln) 11:56, 27. Sep 2006 (CEST)

Beispieltabelle: C64 ist ein denkbar schlechtes Beispiel, da er zuzüglich zum framebuffer ja noch ein extra Farbspeicher besitzt! Gibt/gab es denn nie ein bekanntes System mit echter S/W Darstellung in dieser Auflösung (z.B. Gameboy classic)?

Diese Auflösung wird auch von DOS in monochrom unterstützt (ob diesen Modus auch irgendwelche DOS-Spiele verwenden ist wiederum eine andere Frage). Hingegen hat der Gameboy Classic eine Auflösung von 160x144 und 4 graustufen, wie man leicht unter Game Boy nachlesen kann. --MrBurns 19:24, 31. Jul. 2008 (CEST)

Textmodus (z.B. [...] im Konsolenmodus unter Linux)

Das stimmt nicht ganz. Gewöhnlich ist die Framebuffer-Unterstützung im Kernel heute aktiviert, dann läuft die Text-Konsole im Grafikmodus. Tippe cat /dev/mem > /dev/fb0 für bunten Pixelschnee! -- Sloyment 15:08, 1. Apr. 2008 (CEST)

ändere es bitte dementsprechend. ich würde es ja selber tun, bin aber nicht so der linuxprofi. gruß --Murkel ^(anmurkeln) 19:41, 1. Apr. 2008 (CEST)

KiB und Mib bei den Beispielen

Hi, kann mir bitte jemand vorrechnen, warum 32000 = 4 KiB und 18874368 = 2,25 MiB sein soll? Meiner Meinung nach sind das 32 KB und 18 MB! --134.100.206.196 12:09, 28. Jul. 2008 (CEST)

es sind 32000 und 18874368 bits; rechtsseitig des gleichheitszeichens stehen bytes. damit sollte es klar sein. gruß --Murkel ^(anmurkeln) 20:49, 28. Jul. 2008 (CEST)