3 Wer, wie, was. Wieso, weshalb, warum?

• Wie verhalten sich Pixelwert, VDI-Index und Farbtabellen-Index zueinander?
   
  Der Pixelwert ist der Wert, den das VDI in den Bildschirmspeicher oder in eine Bitmap schreibt, wenn ein Pixel in einer bestimmten Farbe ausgegeben werden soll. Er hängt von der Farbtiefe der Bitmap und deren Pixelformat ab. So hat z.B. bei 8 Bit Farbtiefe ein weißes Pixel i.a. den Pixelwert $00, bei 32 Bit Farbtiefe aber den Pixelwert $00ffffff.
   
  Der Farbtabellen-Index indiziert - wie es der Name bereits andeutet - eine Farbtabelle (eine COLOR_TAB-Struktur), d.h. Index 0 verweist auf Farbeintrag 0 (eine COLOR_ENTRY-Struktur) und Index 1 verweist auf Eintrag 1 der Tabelle. Die Farbtabellen werden für Bitmaps mit bis zu 8 Bit Farbtiefe benötigt und legen für jeden Pixelwert den Farbwert fest; der Farbtabellen-Index entspricht bei bis zu 8 Bit Farbtiefe also letztendlich dem Pixelwert.
   
  Bei mehr als 8 Bit Farbtiefe wird die Farbe direkt durch den Pixelwert angegeben. Man spricht z.B. bei 32 Bit Farbtiefe auch von xRGB-Pixeln, weil der Pixelwert aus einem unbenutzten Byte (x) und drei Bytes für die Farbkomponenten Rot (R), Grün (G) und Blau (B) besteht.
   
  Der VDI-Index ist eine Altlast aus der VDI-Definition von DRI und wird bei Funktionen wie vst_color() oder vsf_color() übergeben. Er ist letztlich ein "verkappter" Farbtabellen-Index, d.h. VDI-Index 0 verweist auf Farbeintrag 0, aber VDI-Index 1 verweist z.B. auf Farbeintrag 255 oder 15 (abhängig von der Farbtiefe). VDI-Index und Pixelwert sind nicht identisch!
   
• Was ist eine inverse Farbtabelle?
   
  Damit Bitmaps in unterschiedlichen Bittiefen und mit unterschiedlichen Farbtabellen schnell umgewandelt werden können, werden sogenannte "inverse Farbtabellen" benötigt. Daraus wird die Information entnommen, welcher Pixelwert der Zielbitmap eine ähnliche Farbe hat wie ein Pixelwert aus der Quellbitmap.
   
  Sobald die Farben des Bildschirms (oder einer anderen Zielbitmap von vr_transfer_bits) verändert werden, muß NVDI bei der nächsten Bitmapausgabe diese inverse Farbtabelle wieder aktualisieren, damit die Zuordnung von Farbwert zu bestem Pixelwert stimmt.
   
  Damit diese Synchronistation zwischen Farbtabelle und inverser Farbtabelle klappt, haben die Farbtabellen eine Kennung <map_id>. Wenn ein Programm selber eine Zielbitmap verwaltet, für die eine Referenz auf eine inverse Farbtabelle angefordert wurde, und das Programm die Einträge in der Farbtabelle verändert, so muß bei v_get_ctab_id() eine neue Kennung für die Farbtabelle angefordert werden, damit die inverse Farbtabelle ggf. aktualisiert wird.
   
• Wieso kann die inverse Farbtabelle verschiedene Auflösungen haben?
   
  Von der Auflösung der inversen Farbtabelle (3, 4 oder 5 Bit) hängt es ab, wie genau die Zuordnung von Farbwert zu Pixelwert ist. Bei 3 Bit wird vereinfacht gesagt ein Feld rgb_to_pixel[8][8][8] aufgebaut, daß mit den drei obersten Bits (2^3 ergibt 8 Einträge pro Dimension) jeder Farbkomponente indiziert wird.
   
  Es gehen also effektiv 5 Bit verfügbarer Farbinformation verloren und farblich nahe beieinanderliegende Pixel können in dieser Tabelle evtl. nicht auseinandergehalten werden. Nachteil ist also, daß bei geringerer Auflösung der inversen Farbtabelle das Dithering oder die arithmetischen Verknüpfungen nicht immer die bestmögliche Wandlung vornehmen können. Vorteil ist der geringere Speicherverbrauch und der schnellere Aufbau der Tabelle.
   
  Falls eine Zielbitmap Pixel mit direkten Farbwerten hat (also 15, 16, 24 oder 32 Bit xRGB), so ist die inverse Farbtabelle nur ein Dummy, da die Zuordnung von Farbwert von Pixelwert eindeutig ist und sich nicht ändern kann. Aus diesem Grund ist bei vr_transfer_bits() auch dokumentiert, daß für solche Bitmaps keine inverse Farbtabelle vorhanden sein muß.
   
• Wenn ich die aktuelle Palette per vq_ctab() ermittle, muß die COLOR_TAB dabei in irgendeiner Art vorinitialisiert sein? Bisher gibt es nur CSPACE_RGB, aber was, wenn es mal z.B. CSPACE_CMY gibt?
   
  Die Farbtabelle muß vor dem Aufruf von vq_ctab() nicht vorinitialisiert sein. Sie wird immer in dem Farbraum zurückgeliefert, der für die Workstation (das übergebene VDI-Handle) eingestellt ist.
   
  Für die Farbräume ist vorgesehen, daß auch in Zukunft (wenn einmal mehr Farbräume verfügbar sind) jede Workstation im RGB-Farbraum geöffnet wird (ggf. dann mit dem Farbprofil des entsprechenden Geräts verknüpft - aber das ist dann für die Applikation vollkommen unwichtig). Wer auf dem jeweiligen Gerät mit einem anderen Farbraum arbeiten möchte, kann für seine Einstellungen einen anderen Farbraum verwenden (bei vsX_XX_color()) oder kann dann für die Workstation einen anderen Farbraum einstellen, so daß auch die Rückgabe z.B. bei vq_ctab() in diesem anderen Farbraum erfolgt. In jedem Fall wird es dabei aber keine Kompatibilitätsprobleme geben.
   
• Ich habe für eine Bitmap eine inverse Farbtabelle angelegt. Wenn ich jetzt ein IMG in die Bitmap kopiere und die Bitmap anschließend auf dem Schirm ausgebe, wird das Bild mit falschen Farben ausgegeben.
   
  Wenn man eine Referenz auf eine inverse Farbtabelle anfordert, ist eigentlich nur wichtig, daß die übergebene Farbtabelle bereits sinnvolle Werte enthielt (d.h. <map_id>, <color_space>, <no_colors>, etc. müssen sinnvolle Werte enthalten; die Anzahl der Einträge in der Farbtabelle muß in Bezug auf die Bittiefe stimmen).
   
  Falls man nach dem Aufruf von v_create_itab() noch die Einträge in der Farbtabelle ändert (d.h. andere Farben einstellt), muß für die Farbtabelle umbedingt mit v_get_ctab_id() eine neue Kennung angefordert werden, damit das VDI erkennt, daß die inverse Farbtabelle aktualisiert werden muß.
   
• Was passiert in den jeweiligen Transfermodi?
   
  In der Beschreibung von vr_transfer_bits() sind die Operationen der logischen und arithmetischen Transfermodi in symbolischer Schreibweise aufgeführt.
   
• Wo finde ich ein Binding für die neuen Funktionen?
   
  In der Datei VDICOL.C und der zugehörigen Headerdatei VDICOL.H.
   
• Muß man, wenn man eine Referenz auf eine inverse Palette anfordert, diese dann erst selbst irgendwie initialisieren?
   
  Nein. Das Format der inversen Farbtabelle ist aus guten Gründen nicht dokumentiert. Es ist nicht einmal garantiert, daß sich hinter der Referenz auf eine inverse Farbtabelle ein Zeiger verbirgt; es könnte auch ein Handle oder irgendetwas anderes sein. Darum kann man die Referenz nur von NVDI anfordern und auch nur über NVDI wieder freigeben.
   
• Wenn ich eine Offscreen-Bitmap zum Reinzeichnen benötige, die eigentlich nur 4 Farben braucht, was geht schneller: Tatsaechlich eine 2-Bit (oder 4-Bit) Offscreenbitmap zu oeffnen oder gleich eine 8-Bit?. Die Bitmap soll dann anschliessend im T_TRANSPARENT-Modus auf eine 8- bzw. 32-Bit-Bitmap kopiert werden.
   
  Diese Frage läßt sich nicht pauschal beantworten. Für eine schnelle Ausgabe sollte grundsätzlich eines der "packed pixel"-Formate (1,2,4,8,16,32 Bit) verwendet werden.
   
  Wird eine arithmetische Operation durchgeführt, so ist das 32 Bit "packed pixel"-Format am schnellsten. Liegt die Bitmap in geringerer Farbtiefe (8 oder weniger Bits) vor, so muß jedes Pixel vor der arithmetischen Operation erst der RGB-Farbwert ermittelt werden. Wenn die Wahl zwischen 2,4 oder 8 Bit-Offscreenbitmap fallen muß, dann ist das 8 Bit "packed pixel"- Format bei arithmetischen Operationen am schnellsten.
   
  Wenn nur eine logische Operation durchgeführt werden muß und die meiste Zeit für die Expansion benötigt wird, so ist es besser die geringstmögliche Farbtiefe zu nehmen (die Expansion von 4 Bit -> 32 Bit verläuft doppelt so schnell wie die von 8 -> 32 Bit).
   
• Muß ich immer mit Farbtabelle und inverser Farbtabelle arbeiten?
   
  Nein. Damit vr_transfer_bits() leichter gehandhabt werden kann, gibt es für häufige Sonderfälle Vereinfachungen beim Aufruf:
   
  • Wenn die Quelle keine Farbtabelle hat (0L), wird die Farbtabelle des Geräts genommen, wenn dieses die gleiche Bittiefe hat. Ist das nicht der Fall, wird die Systemfarbtabelle für die Bittiefe der Quelle benutzt.
  • Wenn das Ziel keine (inverse) Farbtabelle hat (0L), wird die (inverse) Farbtabelle des Geräts genommen, wenn dieses die gleiche Bittiefe hat. Ist das nicht der Fall, wird die Systemfarbtabelle für die Bittiefe des Ziels benutzt und für jeden Aufruf wird extra intern eine inverse Farbtabelle aufgebaut. Daher sollten Zielbitmaps, wenn sie keine inverse Farbtabelle haben, umbedingt die gleiche Bittiefe wie das zum VDI-Handle gehörende Gerät haben. Andernfalls dauern die Aufrufe von vr_transfer_bits() unnötig lange.
  
  Hinweis: Es empfiehlt sich, für Bitmaps außerhalb des Bildschirms mit v_open_bm() oder v_opnbm() eine Bitmap vom VDI erzeugen zu lassen, da man sich in diesem Fall nicht um die Verwaltung von Farbtabellen und inversen Farbtabellen kümmern muß.