SetPixel reicht doch ... nicht

Als sich mein Wechsel von Pascal zu Assembler (unter DOS) vollzog, war es für mich ein Spaß, mit Grafiken zu spielen. Da gab es dann immer wieder Vergleiche zwischen meinen damals 3 Rechnern: Pentium, 486 und 386.

Bei mir bildete sich dann die Meinung:

Es reicht eine plattformabhängige Funktion SetPixel(), die einen Pixel auf dem Schirm einfärbt, und alles andere kann plattformunabhängig implementiert werden.

OK, ich war jung und wusste es nicht besser …

Denkt man nur an Rastergrafik und ignoriert Transparenz, dann ist das theoretisch zumindest nicht ganz falsch. Man kann die wichtigsten Grafikprimitiven wie Linien, Rechtecke, Polygone in einzelne Pixel zerlegen und Punkt für Punkt zeichnen.

Aber viel ineffizienter geht das eigentlich nicht mehr, wenn man zB. beim Füllen eines Rechtecks wirklich pro Pixel eine Funktion aufruft, die wieder auf’s Neue die Koordinaten in eine Rasterposition umrechnet.

Also sollte man sich schon bemühen, dass man zumindest die wichtigsten Operationen einigermaßen effizient anpasst und separat implementiert.

Recht früh fand ich in einem Codebeispiel damals den Bresenham-Algorithmus für das Abbilden einer Linie. (Ich wusste damals nur nicht, dass der so hieß…)
Zuvor nutze ich mein Wissen aus der Schule über Vektoren und schritt eine Linie in Einheitsvektoren in Fließkommazahlen ab.
Dagegen war Bresenham natürlich eine Rennsau. Besonders in Puffern für Rastergrafiken lässt sich gegenüber einem “SetPixel()” eine ordentliche Optimierung erreichen, wenn man die Pixelzellen direkt über Pointer benutzt und nicht jedes mal aufs Neue X und Y in einen Index umrechnen muss.

Und dann kamen OpenGL und DirectX.

Damit musste ich gedanklich lange kämpfen, dass es da den Pixel als Einheit gar nicht mehr gab. Und so muss man sich hinsetzen und nachrechnen, welche Matrixelemente für welche Größe stehen, damit ein sinnvolles Bild entsteht.

In Vektorgrafiken findet man oft ein Fließkomma-Koordinatensystem von z.B.: 0.0 - 1.0 vor. Egal wie groß das final angezeigte Bild ist, wir starten immer bei 0.0 an einem Rand und gehen bis 1.0 am anderen Rand.

Alles in allem bleiben diese Rechenspiele für mich stets eine Herausforderung, denn am anderen Ende der Welt, im Betriebssystem, landen wir dann dennoch wieder auf einer klassischen Pixel/Rastergrafik.
Das gilt sowohl für Windows, wie auch für X11. Zumindest die Größe des umschließenden Fensters wird weiter in Pixel vermessen.

SetPixel() alleine ist also überholt. Das Wissen, wie man damit umgeht jedoch nicht. Und sogar für OpenGL und DirectX brauchen wir Texturen, die … was sind? … Ach ja, Pixelgrafiken! ;)