Embedded Graphic Driver & Graphic Engine für TFT

[Alexander L. (alexander82)]

Hallo Leute,

aktuell bin ich an der Entwicklung eines Grafiktreibers auf einem ARM 
Cortex M4 mit TFT-Controller. Leider finde ich nur sehr schwer 
Informationen zu den Funktionsweisen von Grafikadaptern & Treibern. 
Daher hier mal meine bisherige Umsetzung:

Hardware:
   - CPU ARM Cortex M4 (mit FPU) 168MHz
   - 8 MB SDRAM
   - RGB666 - Interface
   - LCD-Display 320x200pxl (ILI9341)
   - integrierter TFT-Controller kann 2 Layer mit Alphablending

Bisher habe ich zwei Softwarekomponenten.

Grafikbibliothek - GCU (Graphic Control Unit):
   - beinhaltet LowLevel-Funktionen
   - LCD-Initialisierung
   - TFT-Controller-Steuerung
      # RGB-Format (RGB555, RGB656, RGB4444, ARGB8888)
      # Screenformat (Größe, Orientierung)
      # Layer enable, disable
      # Set Alphablending
      # Set Background Color
   - Verwaltungsstruktur für 2 Framebuffer mit jeweils 2 Layern (Größe, 
Farbformat, Screen-Start, Screen-Ende, aktiver Framebuffer, Layer 1/2 
enable, Pointer zu den Framebuffer)
   - Switch Framebuffer

Grafikbibliothek - Graphics:
   - beinhaltet grundlegende Grafikfunktionen (alle Grafikfunktionen 
werden im richtigen Farbformat automatisch in den inaktiven Framebuffer 
und angegebenen Layer geschrieben, erst nach einem Switch_Buffer() wird 
dieser auf dem LCD dargestellt)
   - SetPixel(x,y,Layer,color)
   - ReadScrPixel(x,y,Layer)    // liest aus dem aktiven Framebuffer!!
   - DrawLine(x0,y0,x1,y1,Layer,color)   // Bresenham-Algorithmus 
(horizontale, verticale und diagonale Linien werden beachtet)
   - DrawRect(x0,y0,x1,y1,Layer,color)
   - DrawFilledRect(x0,y0,x1,y1,Layer,color)
   - DrawLineAntiAliased(x0,y0,x1,y1,Layer,color)   // Farbintensität 
wird ohne Alpha über Lightning (HSL) berechnet und im ARGB-Format über 
den Alpha-Kanal

   - Helferfunktionen (nur intern, werden von DrawLine verwendet)
      # Draw_hLine(y0,y1,Layer,color)
      # Draw_vLine(x0,x1,Layer,color)

   - geplante Funktionen
      # DrawEllipse(x0,y0,x1,y1,Layer,color)
      # DrawFilledEllipse(x0,y0,x1,y1,Layer,color)
      # DrawArc(x0,y0,x1,y1,angle1,angle2,Layer,color)
      # DrawFilledArc(x0,y0,x1,y1,angle1,angle2,Layer,color)
      # WriteImage(x0,y0, *pImage, width,height, Layer, RGB_Format)  // 
Falls notwendig, muss das Pixelformat geändert werden, ansonsten einfach 
memcpy()


Das System ist Double-Buffered und die Grafikfunktionen bearbeiten immer 
den inaktiven Framebuffer, welcher anschließend durch einen 
Switch_FrameBuffer() aktiv wird (der vorherig aktive wird jetzt zum 
inaktiven).

Für grundlegende Zeichenfunktione ist alles OK.
Im nächsten Schritt möchte ich 2D rendern, also Bildtransformationen 
durchführen, wie zum Beispiel Rotation oder Grafikeffekte wie Fire, 
Plasma bis hin zum großen Zwischenziel Raycasting mit Texturen.

Erst im letzten Schritt würde ich den 3D-Render umsetzen.


Meine Frage: Ist so eine Funktionsweise üblich oder habe ich dadurch 
Nachteile? Beim Rendern müsste ich teilweise externe Speicher verwenden 
und diese in den Framebuffer mit WriteImage() schreiben...