DE3855234T2

DE3855234T2 - Hochleistungsfähiges graphisches endgerät sowie betriebsverfahren dafür

Info

Publication number: DE3855234T2
Application number: DE3855234T
Authority: DE
Inventors: William Armstrong; David Carver; Steven Dipirro; Peter Doyle; John Ellenberger; Branko Gerovac; Ellen Gibson; Ellis Jones; William Roach; Kevin Rushforth; Raymond Shapiro
Original assignee: Digital Equipment Corp
Current assignee: Digital Equipment Corp
Priority date: 1987-08-13
Filing date: 1988-08-12
Publication date: 1997-01-09
Anticipated expiration: 2008-08-13
Also published as: EP0329771B1; EP0329771A1; DE3855234D1; WO1989001664A1; US5155822A; JPH03501176A

Description

Hintergrund der Erfindung

A. Gebiet der Erfindung

Die Erfindung bezieht sich auf einen Computergraphik-Arbeitsplatz, genauer auf einen selbständigen Hochleistungs-Graphikarbeitsplatz, der einen digitalen Host-Computer und ein Graphikverarbeitungs-Untersystem enthält. Die Erfindung schafft effiziente Steuerstrukturen, um eine maximale Nutzung der Systembetriebsmittel zu erreichen und um die Operation zwischen essentiellen, mittels Daten angesteuerten, unabhängigen oder asynchronen Komponenten (im folgenden wird nur "asynchron" verwendet) effektiv zu koordinieren und somit sowohl zweidimensionale als auch dreidimensionale hochauflösende Graphikanzeigen zu ermöglichen.

B. Graphiksysteme des Standes der Technik

In den letzten Jahren sind bei der Nutzung von Computersystemen zur Erzeugung und visuellen Anzeige von Zeichen und graphischen Ausgangsdaten beträchtliche Fortschritte gemacht worden. Die frühen Systeme waren auf zweidimensionale Anzeigen beschränkt, die häufig unter Verwendung alphanumerischer Zeichen verwirklicht wurden. Das Vermögen zur Erzeugung von Graphikdaten solcher frühen Systeme war begrenzt, wobei bestimmte Zeichendarstellungen mit vorgegebener Größe und Form in einem Zeichendatenspeicher gespeichert waren und vom Benutzer bei Bedarf in einen Anzeigespeicher übertragen werden konnten, um die Anzeigefähigkeiten des Systems zu erweitern. Ein bemerkenswerter Fortschritt in der Computergraphiktechnik verwendete ein sogenanntes "Bitraster"-Graphikanzeigesystem, um Ausgangsdaten in einem Anzeigespeicher zu speichern. Der "Bitraster"-Lösungsansatz visualisiert die Ausgangsdaten als eine zweidimensionale Pixelmatrix, wobei jedes Pixel einem einzelnen Bildelement auf der Anzeigevorrichtung entspricht. Bei einer zweidimensionalen Schwarz- Weiß-Graphikanzeige benötigt jedes Pixel nur ein Bit an Information, d. h. entweder 0 oder 1, um Schwarz bzw. Weiß darzustellen. Somit können alle Pixel für eine zweidimensionale Schwarz-Weiß-Anzeige in Form eines zweidimensionalen Rasters vorliegen, wobei die Informationsbits im Raster die Ausgangsdaten enthalten, die die Anzeigevorrichtung darstellt.
Es ist klar, daß die Graphikanzeige eines dreidimensionalen Gegenstandes in Farbe im Gegensatz zu einem zweidimensionalen, schwarzweißen Gegenstand in die Menge der Ausgangsdaten, die zur Darstellung auf der Anzeigevorrichtung erforderlich sind, und die zur Verarbeitung der Ausgangsdaten für die Anzeige auf einer Katodenstrahlröhre erforderliche Verarbeitungskapazität des Graphiksystems beträchtlich erhöht. Allein hinsichtlich der Farbe können z. B. acht Bits an Informationen pro Pixel erforderlich sein, um die Informationen für die Rot-, Grün- und Blauanteile der Farbe und die Intensität der Farbe für dieanzeige zu speichern.
Der Bitraster-Lösungsansatz wurde im Stand der Technik auf ein Ebenenkonzept erweitert, bei dem eine dreidimensionale Matrix mit separat beabstandeten, parallelen Ebenen visualisiert wird, wobei jede Ebene einem Attribut der Earbinformationen entspricht, d. h. eine rote Ebene, eine grüne Ebene, eine blaue Ebene sowie eine Intensitätsebene. Jedes Pixel umfaßt Bits, die auf separaten Ebenen gespeichert sind, wobei die Datenverarbeitung erfordert, daß das Graphiksystem die separaten Bits eines Pixels aus verschiedenen Speicherstellen wiedergewinnt.
Wenn andere Attribute und Anzeigeeigenschaften wie z. B. eine dreidimensionale Anzeige, Schattierungen, Oberflächenreflexionseigenschaften, Objektdrehung usw. zum Graphiksystem hinzugefügt werden sollen, müssen die Speicherstruktur und -kapazität und die Datenverarbeitungsfähigkeit des Systems beträchtlich erweitert werden, um ein Objekt darzustellen und visuell anzuzeigen. Solche Kapazitäts-, Struktur- und Verarbeitungsfähigkeitsanforderungen haben die Durchführbarkeit der Implementierung eines dreidimensionalen Hochleistungs-Graphiksystems als ein selbständiges Arbeitsplatzsystem, insbesondere als Graphiksystem mit Mehr-Benutzer-Fähigkeit, allgemein eingeschränkt. Obwohl technische Fortschritte wie z. B. ein 32-Bit-Wort-Mikroprozessor eine Hardwaregrundlage für eine Implementierung eines selbständigen Arbeitsplatzes für ein Graphiksystem schaffen, bleiben enorme Datenstruktur-, Verarbeitungs- und Systembetriebssteuerungs- Anforderungen, um ein effektives Hochleistungs-Graphikarbeitsplatzsystem zu erreichen, das Mehrfach-Anwendungsprozesse verarbeiten kann, um eine Mehr-Benutzer-Implementierung zu ermöglichen. Diese Anforderungen wurden im Stand der Technik nicht ausreichend berücksichtigt.
Von W. M. NEWMAN u. a.: "Principles of interactive computer graphics", McGraw-Hill, 1979, 5. 101-103, ist ein Anzeigedatei-Compiler bekannt, der durch die Verwendung einer doppelten Pufferung einer segmentierten Anzeigedatei eine ununterbrochene Auffrischung sicherstellt.

Zusammenfassung der Erfindung

Es ist daher eine Hauptaufgabe der Erfindung, einen selbständigen Graphikarbeitsplatz zu schaffen, der die Datenstruktur, die Verarbeitung und die Systembetriebssteuerung bietet, die für eine hochauflösende Hochleistungs- Graphikanzeige mit Mehr-Benutzer-Fähigkeit erforderlich sind.
Das System der Erfindung umfaßt allgemein eine Host-Zentraleinheit, die mittels einer Zwischenverarbeitungseinheit und einer Busanordnung mit einem Graphik-Untersystem verbunden ist. Das Host-Untersystem kann betrieben werden, um ein oder mehrere Anwendungsprogramme auszuführen, die im Host resident sind, um Graphikdatenstrukturen aufzubauen, die anzuzeigende, zweidimensionale und/oder dreidimensionale Objekte darstellen. Die Graphikdatenstrukturen sind in einer Strukturspeicherkomponente im Graphik-Untersystem gespeichert. Die dreidimensionalen Graphikdatenstrukturen sind jeweils als hierarchische Graphikdatenknotenstruktur im Strukturspeicher implementiert. Für eine ausführliche Diskussion der Hauptkonzepte der interaktiven Computergraphik, wie sie im allgemeinen vom System der Erfindung verwendet werden, sollte auf Fundamentals of Interactive Computer Graphics von J. D. Foley und A. Van Dam (Addison-Wesley 1982) Bezug genommen werden.
Jeder Knoten ist als eine fundamentale Speichereinheit definiert, um Graphikdaten oder Anweisungen zu enthalten, die sich auf die Primitive, Transformationen, Attribute usw. der Graphikstruktur beziehen, die entsprechend einem bestimmten Anwendungsprogramm, das im Host resident ist, unter Verwendung von im voraus ausgewählten strukturierten Graphikroutinen, die in einer Speicherbibliothek ebenfalls im Host gespeichert sind, aufgebaut ist. Eine asynchrone Operationsstruktur-Abarbeitungsvorrichtung durchquert eine spezielle Steuerstruktur, die im Strukturspeicher gespeichert ist, auf einer wiederholten oder kontinuierlichen Grundlage (im folgenden wird normalerweise "kontinuierlich" verwendet), um Anforderungen zur Durchquerung der Knoten der Graphikstrukturen zu lesen und zu verarbeiten und um die Daten und Anweisungsinformationen, die in den Knoten enthalten sind, zur Verarbeitung, Manipulation und Anzeige durch die Graphikverarbeitungskomponenten des Graphikuntersystems über eine Graphik-Pipeline nach unten zu senden.
Die Erfindung ist in den Ansprüchen 1 und 7 definiert. In den übrigen Ansprüchen sind bestimmte Ausführungsformen definiert.
Gemäß einem wichtigen Merkmal der Erfindung wird eine Durchquerungssteuerfunktion unter den Host- und Graphikuntersystem-Komponenten aufgeteilt, um Anforderungen für Graphikstrukturdurchquerungen anzunehmen, die von konkurrierenden Anwendungsprogrammen erzeugt werden, und um solche Durchquerungen anschließend einzuteilen und durchzuführen, derart, daß jede der konkurrierenden Graphikanwendungen das Graphikverarbeitungs-Untersystem als eigenes System betrachtet und mit der effektivsten Nutzung der Systemkomponenten ausgeführt werden kann. Die hierarchische Knotenspeicherstruktur, die asynchrone oder unabhängige Speicherdurchquerung (im folgenden wird nur "asynchron" verwendet) und die Überwachungs-Durchquerungssteuerfunktionen erleichtern eine dreidimensionale Hochleistungs-Anzeigefähigkeit innerhalb des Systems, indem sie eine effiziente Zuteilung der Systembetriebsmittel schaffen, um komplexe Graphikdatenstrukturen zu speichern und die Graphikdatenstrukturen in geordneter und koordinierter Weise zu verarbeiten. Das System der Erfindung nutzt wirksam eine effiziente Koordination und Steuerung der fortschreitenden, mittels Daten angesteuerten, asynchronen Operation der Graphikuntersystemkomponenten, um alle Systembetriebsmittel bei der Abarbeitung mehrerer im Host residenter Anwendungsprogramme gleichmäßig zu verteilen, um somit eine Mehr-Benutzer-Fähigkeit zu ermöglichen.
Entsprechend den bekannten Konzepten interaktiver Computergraphik verwendet die Erfindung ein Fenstersystem, um eine Umsetzung vom Weltkoordinatensystem des Benutzers in geeignete geometrische Koordinaten durchzuführen, die für die physikalische Anzeigevorrichtung des Arbeitsplatzes, d. h. für die Katodenstrahlröhre, geeignet sind. Ein Fenster ist eine rechtwinklige Matrix von Pixeln, die in Abhängigkeit von der Größe des Fensters relativ zu den physikalischen Abmessungen des Anzeigebildschirms teilweise oder vollständig auf der Anzeigevorrichtung sichtbar sein können. Fenster liegen ferner in einer Hierarchie vor, die ein "Stamm"-Fenster und Unterfenster oder "Ableger" umfaßt. Fenster können in ihrer Größe verändert werden, wobei Unterfenster durch das Stammfenster gekappt werden, wenn ein Unterfenster größer dimensioniert wird als das Stammfenster, um Abschnitte einer Anzeigevorrichtung, die von einer Graphikstruktur definiert werden, detailliert anzuzeigen. Wie in der folgenden Beschreibung einer bevorzugten Ausführungsform der Erfindung genauer beschrieben wird, ist das X-Window-System, das unter der Schirmherrschaft des Massachusetts Institute of Technology als lizenzgebührenfreier Jndustriestandard entwickelt worden ist, ein sehr vorteilhaftes Fenstersystem zur Verwendung in Verbindung mit der Anzeige der von den Anwendungsprogrammen erzeugten Graphikdatenstrukturen. Gemäß der Erfindung sind die vom Fenstersystem erzeugten Daten zur Erzeugung und Definition der Fensterkoordinaten und -attribute für die Korrelation mit der hierarchischen Graphikdatenknotenstruktur des innerhalb der rechtwinkligen Matrix des Fensters anzuzeigenden Objekts durch das Durchquerungssteuersystem eindeutig identifiziert.
Dementsprechend kann die asynchrone Durchquerung mittels der Strukturabarbeitungsvorrichtung korrelierte Graphikstrukturdaten und Anweisungen sowie Fensterdaten für die Graphikverarbeitungskomponenten erzeugen. Die Fensterdaten-Graphikstrukur-Korrelations funktion der Durchquerungssteuerung erleichtert ferner eine dreidimensionale Hochleistungs-Graphikanzeige, indem sie die Verwendung eines sehr effektiven Fenstersystems wie z. B. des X-Window-Systems ermöglicht, das hauptsächlich für die Verwendung in zweidimensionalen Bitraster-Graphiksystemen entwickelt wurde. Die Fensteridentifikationsdaten für die Korrelation mit den dreidimensionalen Knotenspeicherstrukturen führen in das vorteilhafte X-Window-System systematisch eine dreidimensionale Funktionalität ein.
Gemäß einem weiteren bedeutenden Merkmal der Erfindung ist parallel zu den dreidimensionalen Komponenten ein separates zweidimensionales Bitraster-Graphiksystem vorgesehen, um zweidimensionale Anwendungsprogramme zu verarbeiten. Das Bitraster-Graphiksystem besitzt Betriebsmittel, die für zweidimensionale Graphiken geeignet sind und einen Bitrasterspeicher sowie einen Wiedergabeprozessor umfassen, um Bitrasterdatenanweisungen im Strukturspeicher zu durchqueren. Außerdem wird der Strukturspeicher von den parallelen dreidimensionalen und zweidimensionalen Graphiksystemen gemeinsam genutzt, um sowohl als dreidimensionaler Graphikstrukturspeicher als auch als zweidimensionaler Bitrasterspeicher zu dienen. Der Wiedergabeprozessor wird ebenso von den parallelen Graphiksystemen gemeinsam genutzt, um sowohl Bitrastergraphiken als auch die Polygonwiedergabe für dreidimensionale Objekte zu verarbeiten. Auf diese Weise sind die Systembetriebsmittel mit dreidimensionalen Fähigkeiten nicht mit Verarbeitungsaufgaben überlastet, die sich auf zweidimensionale Anzeigen beziehen, wobei die funktionalen Fähigkeiten, die sich sowohl mit den dreidimensionalen als auch den zweidimensionalen Prozessen überschneiden, gemeinsam genutzt werden, um die Anzahl der Hardwarekomponenten im System zu verringern.
Eine bessere Operationseffizienz wird erreicht, indem die Adreßdaten, die sich auf die Graphikuntersystemkomponenten beziehen, in den virtuellen Speicher des Host-Systems abgebildet werden. Die im Host residenten Anwendungsprozesse können somit direkt mit den Graphikuntersystemkomponenten, wie z. B. dem Strukturspeicher, kommunizieren, ohne daß eine Hardwareeinrichtung für direkten Speicherzugriff oder Gerätetreiber erforderlich sind.
Dementsprechend erreicht die vorliegende Erfindung eine dreidimensionale Hochleistungsgraphikfähigkeit, die durch Maximierung der Verarbeitungsfähigkeiten der interaktiven Komponenten in einer selbständigen Arbeitsplatzkonfiguration durchführbar ist. Im Speicher werden hierarchische Datenstrukturen aufgebaut, um die Definition komplexer Datenstrukturen zu ermöglichen, die Primitive, Ättribute und geometrische Transformationen dreidimensionaler Objekte darstellen. Die asynchrone Durchquerung der im Speicher aufgebauten Datenstrukturen und die Durchquerungssteuerfunktionen koordinieren und kontrollieren gemeinsam den Fluß der Graphikdaten und Anweisungen zu einer Graphik-Pipeline für eine geordnete Verarbeitung und Anzeige, derart, daß eine effiziente Verarbeitung und Anzeige mehrerer Anwendungsprozesse leicht möglich ist.
Für ein besseres Verständnis der obenbeschriebenen Merkmale und weiterer Merkmale und Vorteile der Erfindung wird auf die folgende genaue Beschreibung einer bevorzugten Ausführungsform der Erfindung und auf die beigefügten Zeichnungen Bezug genommen.

Kurzbeschreibung der zeichnungen

Fig. 1 ist ein Blockschaltbild eines Computergraphiksystems gemäß der vorliegenden Erfindung.
Fig. 2 ist ein Blockschaltbild des Graphikuntersystems der Fig. 1.
Fig. 3 ist ein Blockschaltbild der Softwareorganisation für das Computergraphiksystem der vorliegenden Erfindung.
Fig. 4 ist ein Blockschaltbild des Strukturspeichers des Graphikuntersystems der Fig. 2.
Fig. 5 ist ein Blockschaltbild der Organisation einer Knotenspeicherstruktur einer Graphikdatenstruktur gemäß der vorliegenden Erfindung.
Fig. 6 ist ein Blockschaltbild der BI-Bus-Speicherabbildung der Erfindung.
Fig. 7 ist ein auseinandergezogenes Blockschaltbild des umgekehrten E/A-Bereichs des Blockschaltbilds der Fig. 6.
Fig. 8 ist ein Blockschaltbild des Graphikkontextes und des Durchquerungsmodells für die Bitrastergraphik-Verarbeitung.
Fig. 9 ist ein Blockschaltbild des Bitraster-Stamms.
Fig. 10 ist ein Blockschaltbild des Bitraster-Graphikkontextes.
Fig. 11 ist ein Blockschaltbild der Bitraster-Zellenmatrix.
Fig. 12 ist ein Blockschaltbild des Bitraster-Anzeigekontextes.
Fig. 13 zeigt in Blockschaltbildform die Verbindung zwischen einem Graphikkontext und den virtuellen Stammknoten einer Datenstruktur.
Fig. 14a, b, c zeigen Beispiele verschiedener Referenzknoten.

Genaue Beschreibung einer bevorzugten Ausführungsform der Erfindung

Systemübersicht

In Fig. 1 ist in Blockschaltbildform das Graphikarbeitsplatzsystem gemäß der Erfindung dargestellt. Ein Host-Untersystem enthält eine Host-Zentraleinheit 10, einen Host-Speicher 11, eine Bandsteuervorrichtung 12, einen Steuerprozessor 13 sowie eine Plattensteuervorrichtung 14. Die Host-Untersystemkomponenten 10, 11, 12, 13 sind über einen Bus 15 miteinander verbunden.
Ein bevorzugtes Host-Untersystem zur vorteilhaften Implementierung der Lehren der Erfindung umfaßt einen Scorpio- oder Digital-KA825-Host-Prozessor, der als Host-Zentraleinheit 10 verwendet wird, ein 4mbyte-MS820-BA-Speichermodul als Host-Speicher 11, ein lokales Netz DEBNX- Ethernet und ein TK50-9smbyte-Streamer-Bandlaufwerk als Bandsteuervorrichtung 12, ein RD54-150MByte-Festplattenlaufwerk und ein RX50-818kByte-Diskettenlaufwerk als Plattensteuervorrichtung 14, einen Aurora- oder Digital- KA800-Steuerprozessor als Steuerprozessor 13 sowie eine VAX-Busverbindung oder einen synchronen, Zeitmultiplex-32bit-Bus VAX-BI als Bus 15. Der Scorpio-Prozessor ist ein Ein-Platinen-VAX-Prozessor, der den vollständigen VAX-Befehlssatz ausführt und entweder mit dem VMS- oder dem ULTRIX-Betriebssystem und entsprechenden Anwendungen betrieben wird. Der Scorpio-Host-Prozessor, der Aurora- Steuerprozessor, der VAX-BI-Bus und andere Host-Untersystemkomponenten werden von der Digital Equipment Corporation vertrieben.
Der Steuerprozessor 13 ist mit einem lokalen oder II32- Bus 16 versehen, um den Steuerprozessor 13 mit einem Graphikuntersystem 17 zu verbinden. Der Aurora-Steuerprozessor 13 wirkt somit als Schnittstelle zwischen dem Graphikuntersystem 17 und dem BI-Bus 15. Der Steuerprozessor 13 führt ferner die Eingangs- und Ausgangsvorverarbeitung für interaktive Peripheriegeräte wie z. B. eine Tastatur 18, einen Druckknopfkasten 19, eine Maus 20, ein Tablett 21 sowie einen Wählkasten 22 aus, die mittels eines Peripherieverstärkerkastens 23 über eine serielle Datenleitung 24 mit dem Steuerprozessor 13 verbunden sind, wie in Fig. 1 dargestellt ist. Der Peripherieverstärkerkasten 23 wird verwendet, um die Peripheriegeräte 18, 19, 20, 21, 22 am Monitorplatz mit Leistung zu versorgen und Peripheriesignale von den Peripheriegeräten 18, 19, 20, 21, 22 zu sammeln. Der Peripherieverstärkerkasten organisiert die gesammelten Peripheriesignale, indem er die Signale zu Paketen zusammenfaßt und diese Pakete über den Steuerprozessor 13 zur Host-Zentraleinheit 10 sendet. Der Peripherieverstärkerkasten 23 empfängt ferner Pakete von der Host-Zentraleinheit 10 über den Steuerprozessor 13, entpackt die Daten und sendet die entpackten Daten zu den entsprechenden Peripheriegeräten 18, 19, 20, 21, 22. Für eine genauere Beschreibung der Eingangs- und Ausgangsvorverarbeitungsfunktionen des Steuerprozessors 13 und des Peripherieverstärkerkastens 23 soll auf die europäische Patentanmeldung EP-A-0 303 288 mit dem Titel "Peripheral Repeater Box" Bezug genommen werden, die zum gleichen Datum wie die vorliegende Anmeldung eingereicht wurde.
Außerdem kann der Aurora-Steuerprozessor 13 vorteilhaft verwendet werden, um eine Konsole für die Scorpio-Host- Zentraleinheit 10 zu emulieren. Die Konsolen-Emulation wird durch die Verwendung einer seriellen Datenleitung 25 zwischen dem Steuerprozessor 13 und der Host-Zentraleinheit 10 bewerkstelligt. Der Aurora-Steuerprozessor 13 kann somit verwendet werden, um Diagnose zu betreiben und das Host-Untersystem auszutesten, ohne daß eine zusätzliche Ausrüstung erforderlich ist. Für eine genauere Beschreibung der Konsolen-Emulationsfunktion des Steuerprozessors 13 soll auf die europäische Patentanmeldung EP-A-0 303 290 mit dem Titel "Console Emulation for Graphics Workstation" Bezug genommen werden, die mit dem gleichen Datum wie die vorliegende Anmeldung eingereicht worden ist.
Gemäß der bevorzugten Ausführungsform der Erfindung umfaßt das Graphikuntersystem 17 eine Shadowfox-Graphikkarte, die von der Evans & Sutherland Computer Corporation vertrieben wird. Die Hauptfunktion des Graphikuntersystems 17 ist, Graphikdatenstrukturen zu speichern, die von mehreren in der Zentraleinheit 10 residenten Anwendungsprogrammen aufgebaut worden sind, und die Graphikdatenstrukturen zu verarbeiten, zu manipulieren und anzuzeigen, wie offensichtlich ist. Wie in Fig. 2 gezeigt, enthält der Shadowfox-Graphikkartensatz einen Strukturspeicher 26, der über den lokalen II32-Bus 16 mit dem Steuerprozessor 13 verbunden ist. Wie im folgenden genauer beschrieben wird, umfaßt der Strukturspeicher 26 einen 4MByte-Speicher, um die von den Anwendungsprogrammen in der Host-Zentraleinheit 10 aufgebauten Graphikdatenstrukturen zu speichern.
Eine asynchrone Operationsstruktur-Abarbeitungsvorrichtung 27 ist über den II32-Bus 16 mit dem Steuerprozessor 13 und über einen Strukturspeicherbus 28 mit dem Strukturspeicher 26 verbunden. Die Strukturabarbeitungsvorrichtung 27 ist ein spezieller 32Bit-Bit-Slice-Mikroprozessor, der die im Strukturspeicher 26 gespeicherten Graphikdatenstrukturen auf einer kontinuierlichen oder wiederholten Grundlage durchquert und die Graphikdaten über eine Leitung 30 an den Graphik-Pipeline-Prozessor 29 sendet.
Gemäß der Beschaffenheit und dem Betriebsmodus des Shadowfox-Graphikuntersystems organisiert der Graphik- Pipeline-Prozessor 29 die von der Strukturabarbeitungsvorrichtung 27 empfangenen Daten in Paketen und führt Graphiktrans formationen, Matrixmultiplikationen, Kappungen, Perspektivendivisionen und Arbeitsbereichsabbildungen durch. Daher werden die Graphikdatenstrukturen, wie sie vom Graphik-Pipeline-Prozessor 29 verarbeitet werden, von den Datenstruktur-Weltbereichsdaten, wie sie von einem Benutzer über ein Anwendungsprogramm implementiert werden, in der Host-Zentraleinheit 10 auf der Grundlage des anzuzeigenden Objektes in darstellbare Bildschirmbereichsdaten relativ zu den physikalischen Abmessungen des Bildschirms transformiert.
Zwei Datenabgreifer 31, 32 untersuchen jede Anweisung und jedes Datenpaket, die vom Ausgang des Graphik-Pipeline- Prozessors 29 empfangen werden, um festzustellen, ob die Pakete die Pipeline entlang weiter nach unten zu senden sind oder ob die Daten zu einem Graphikdatenverwalter 33 zu senden sind, der die Pakete zu den entsprechenden Zielen weiterleitet Zum Beispiel werden X-, Y-, Z- und Farb-Datenpakete direkt an eine Delta/Bildtiefensimulation-Berechnungsvorrichtung 34 gesendet, um die Linienneigung, die eingestellten Endpunkte und die Statusmerker zu berechnen, die die Orientierung einer Linie beschreiben. Die Farbdaten und die Z-Daten werden mit Hintergrundfarben gemischt, um relative Rot-, Grün- und Blauwerte zu bestimmen. Die Delta/Bildtiefensimulation-Berechnungsvorrichtungsausgabe wird für Berechnungen in Linienzeichnungsalgorithmen an einen Pixeiprozessor 35 gesendet. Der Graphikdatenverwalter 33 wird verwendet, um alle gültigen zeichenanweisungen in den Pixelprozessor 35 zu laden, und dient ferner zum Puffern der Pipelineanweisungen für einen Wiedergabeprozessor 36 und zum Puffern der Daten vom Wiedergabeprozessor 36 für den Pixelprozessor 35. Wie im folgenden genauer beschrieben wird, wird der Wiedergabeprozessor 36 im dreidimensionalen Graphikprozeß verwendet, um Polygone wiederzugeben.
Der Pixelprozessor 35 umfaßt 16 identische Prozessoren, die unter Verwendung der Endpunkt- und Neigungsdaten, die von der Delta/Bildtiefensimulation-Berechnungsvorrichtung 34 erzeugt worden sind, sowie der Polygonwiedergabedaten, die vom Wiedergabeprozessor 36 erzeugt worden sind, geglättete und bildtiefensimulierte Linien zeichnen. Die Daten vom Pixelprozessor 35 werden zu einem Rahmenpuffer 37 gesendet, der einen 1024 1024 Pixelspeicher umfaßt und das für den Systemmonitor 38 erzeugte Pixelbild enthält. Der Rahmenpuffer 37 erzeugt ein Vollbild-Rasteranzeigeformat mit 1024 1024 Pixel und 60 Hz.
Eine Videosteuervorrichtung 39 empfängt den Ausgang vom Rahmenpuffer 37 und setzt die Signaldaten in ein Analogsignal um, um den Monitor 38 zu treiben. In der bevorzugten Ausführungsform umfaßt der Monitor 38 einen Digital-VR290-DA/D3/D4-19Zoll-Farbmonitor mit einem 1024 864 Pixel großen Bildbereich. Die Videosteuervorrichtung 30 enthält ferner eine Fenster-Nachschlagtabeile, um das Videoformat für die Anzeige zu bestimmen, sowie eine Farben-Nachschlagtabelle mit Farbwerten, um die roten, grünen und blauen Anteile der Pixel zu definieren. Ein Graphikdatenbus 40 verbindet die Videosteuervorrichtung 30 mit den verschiedenen anderen Komponenten des Graphikuntersystems 17, wie in Fig. 2 gezeigt ist.

Untersystemabbildung

Die Untersystemabbildung bezieht sich auf eine Technik, die in der vorliegenden Erfindung verwendet wird, um dem Host-Prozessor 10 zu ermöglichen, auf den lokalen RAM im Steuerprozessor 13, auf den Strukturspeicher 26 und auf verschiedene Register im Graphikuntersystem 17 direkt zuzugreifen. Diese Komponenten werden direkt in den virtuellen Speicher des Host-Systems abgebildet. Die Untersystemabbildung ist sehr vorteilhaft beim Betrieb des Systems der vorliegenden Erfindung, die eine "mittels Daten angesteuerte" Maschine ist, wie offensichtlich ist.
In einem herkömmlichen System verwendet das verfahren, das zum Zugreifen auf eine Hardware außerhalb einer CPU verwendet wird, einen Gerätetreiber. Ein Gerätetreiber ist ein Programm, das speziell für die Handhabung der Kommunikation zwischen einer Host-CPU und einem speziellen Gerät, d. h. einem Speicher, einer Platteneinheit, einer Bandeinheit usw., ausgelegt ist. Wenn somit die CPU auf einen externen Gerätespeicher zugreifen will, verwendet sie einen Gerätetreiber, der entweder direkt durch Verwendung von Registern den Gerätespeicher lädt oder eine Direktspeicherzugriff-(DMA)-Operation einleitet. Für einen DMA lädt der Treiber die Benutzerdaten in den physikalischen Speicher (die DMA-Hardware erfordert, daß die Daten in einen physikalischen Speicher geladen werden), stellt eine Quellen- und eine Zieladresse ein und verwendet anschließend die DMA-Hardware, um die Informationen von der Quelle zum Ziel zu übertragen.
Im allgemeinen ist dieser DMA-Lösungsansatz sehr brauchbar. In einer mittels Daten angesteuerten Maschine jedoch, wie z. B. in der vorliegenden Erfindung, wären die Kosten eines solchen Lösungsansatzes unannehmbar. Im vorliegenden Graphiksystem besteht die Hauptfunktion der Host-Zentraleinheit darin, Anweisungen an das Graphikuntersystem 17 zu senden. Dies würde erfordern, daß die Host-Zentraleinheit 10 für fast jede Operation, die sie durchführt, DMA-Hardware verwendet. Im Hinblick auf dieses Problem wurde somit das Untersystem-Abbildungsschema entwickelt.
Die Host-Zentraleinheit 10 teilt sich den BI-Bus 15 mit dem Systemspeicher 11 und dem Steuerprozessor 13 (siehe Fig. 1). Der lokale Bus des Steuerprozessors ist der II32-Bus 16. Am Bus 16 befinden sich der lokale Steuerprozessor-RAM (1 MByte), lokale Register sowie Komponenten des Graphikuntersystems 17 einschließlich des Strukturspeichers 26, der Strukturabarbeitungsvorrichtung 27, der Graphikpipeline 29, des Graphikdatenverwalters 33, des Wiedergabeprozessors 36, des Pixelprozessors 35 und des Rahmenpuffers 37. Es ist zu beachten, daß nicht alle obenerwähnten Komponenten physikalisch mit dem II32-Bus verbunden sind (siehe Fig. 2). Das Untersystem-Abbildungsschema erlaubt der Host-Zentraleinheit, direkt auf die II32-Bus-Komponenten zuzugreifen.
Um den direkten Zugriff zu bewerkstelligen, werden die Komponenten des II32-Bus 16 in den reservierten E/A-Bereich des BI-Bus-Speicherbereichs abgebildet. Fig. 6 zeigt den BI-Speicherbereich, während Fig. 7 die Einzelheiten des reservierten E/A-Bereichs des Speicherbereichs der Fig. 6 darstellt, in den die Komponenten abgebildet werden. Bei der Systeminitialisierung wird ein Gerätetreiber der Host-Zentraleinheit 10 verwendet, um die Abbildung durchzuführen. Der erste Schritt, den er ausführt, ist das Einrichten zweier Abbildungsregister im Steuerprozessor 13. Die Abbildungsregister werden ihrerseits durch das Betriebssystem in den virtuellen Adreßraum des Host abgebildet. Das erste Register SADR reflektiert die Startadresse des reservierten E/A-Bereichs im BI-Speicherbereich, die 20800000 HEX entspricht. Das zweite Register EADR reflektiert die Endadresse des reservierten E/A-Bereichs im BI-Speicherbereich, die 22000000 HEX entspricht. Dies wird bewerkstelligt, indem der Gerätetreiber einfach die Start- und Endadressen in die entsprechenden Register schreibt. Der Mikrocode des Steuerprozessors 13 legt seinen eigenen lokalen RAM in diesen Adreßbereich. Wenn dieser Schritt durchgeführt ist, ist die physikalische Abbildung verwirklicht.
Der nächste Schritt, den der Host-Gerätetreiber durchführt, ist die Abbildung jeder II32-Komponente (Steuerprozessor-RAM, Strukturspeicher 26 und Register des Graphikuntersystems 17) in den virtuellen Adreßraum (S∅) des Hostsystems. Dieser Schritt ist erforderlich da die Host-Software aufgrund der Integration der Speicherverwaltungs-(MM)-Hardware auf der Host-Zentraleinheit 10 keine physikalische Adresse spezifizieren kann. Diese Hardware ist ständig aktiv und tastet Adressen ab, die von der Host-Zentraleinheit 10 ausgegeben werden. Jede Adresse wird als virtuelle Adresse betrachtet, weshalb die Speicherverwaltungs-Hardware immer versuchen wird, mit dieser Adresse eine Ebene der Übersetzung durchzuführen, um eine physikalische Adresse zu erzeugen. Die Ebene der Übersetzung ist abhängig davon, ob die Adresse eine virtuelle Systemadresse oder eine virtuelle Prozeßadresse ist. Diese Unterscheidung ist wichtig, da diese Adressen jeweils unterschiedliche Übersetzungstabellen und Übersetzungsmechanismen durchlaufen. Virtuelle Prozeßadressen sind prozeßspezifisch, wobei jeder Prozeß sich selbst in den Speicher abbilden muß, wenn er für die vorliegende Erfindung verwendet wird. Dies weist jedem Prozeß 4 MBytes an virtuellem Adreßraum zu, der seinem eigenen Adreßraum hinzugefügt wird. Gemäß der vorliegenden Erfindung kann somit jeder Prozeß auf dem System durch Verwirklichung der II32-Bus-Abbildung in Form virtueller Systemadressen Zugriff auf diesen Bus erhalten, ohne Speicherbetriebsmittel zu verschwenden. Dies verringert ferner die Komplexität der Berechnungen, die zum Bestimmen der physikalischen Adressen, auf die sich das Graphikuntersystem bezieht, verwendet werden.
Der letzte Schritt, den der Host-Gerätetreiber ausführt, ist die Freigabe der S∅-Seiten, die die virtuellen Adressen der II32-Bus-Komponenten enthalten. Durch Freigeben dieser Seiten kann jeder beliebige Prozeß auf dem System auf diesen virtuellen Systemadreßraum zugreifen. Im allgemeinen enthalten die S∅-Seiten Betriebssystemsoftware und Daten, auf die nicht jeder Prozeß zugreifen kann. Wenn eine S∅-Seite gesperrt ist, ist die einzige Möglichkeit, auf diese virtuellen Adressen zuzugreifen, die Verwendung von Systemaufrufen. Dies würde die Komplexität des Systems erhöhen und den Verwaltungsaufwand vergrößern. Durch Freigeben der S∅-Seiten erübrigt sich somit die Verwendung von Systemaufrufen.
Nachdem der Host-Gerätetreiber die obenbeschriebenen Schritte ausgeführt hat, ist die Abbildung abgeschlossen. Nun hat jeder Prozeß direkten Lese/Schreib-Zugriff auf jede der abgebildeten II32-Bus-Komponenten, da diese Komponenten direkt in den virtuellen Speicher des Host abgebildet sind. Jeder Prozeß kann diese Komponenten wie seinen eigenen lokalen Speicher handhaben. Somit erübrigt sich die Notwendigkeit für die Verwendung von Direktspeicherzugriff-Hardware, Gerätetreibern oder Betriebssystemaufrufen.

Speicher- und Softwareorganisation

Aus der obigen Beschreibung wird klar, daß das Graphikuntersystem 17 im wesentlichen in einer asynchronen Betriebsart betrieben wird, die durch die asynchrone Operation der Strukturabarbeitungsvorrichtung 27 bestimmt ist, die wie oben beschrieben den Datenfluß vom Strukturspeicher 26 zu den anderen Komponenten des Graphikuntersystems 17 durch die kontinuierliche, sequentielle Durchquerung der Graphikdatenstrukturen steuert. Der gesamte Datenfluß durch die Graphik-Pipeline ist eine Funktion der Strukturabarbeitungsvorrichtungsoperation. Wie im folgenden genauer beschrieben wird, führt die Host-Zentraleinheit 10 Anwendungsprogramme aus, um Graphikdatenstrukturen in hierarchischen Knotenstrukturen aufzubauen, die die anzuzeigenden dreidimensionalen Objekte darstellen. Die Knotenstrukturen sind im Strukturspeicher 26 gespeichert.

Bedingte Knoten einer Graphikdatenstruktur

Eine Graphikdatenstruktur besteht aus allen Daten, die ein Objekt und die Art seiner Darstellung beschreiben. Eine Graphikdatenstruktur ist eine hierarchische Zusammenstellung von Knoten und Pfaden, die diese verbinden.
Ein Knoten ist ein Satz ausführbarer Anweisungen und Daten. Die Strukturabarbeitungsvorrichtung 27 durchquert der Reihe nach jeden Knoten, wobei sie einem oder mehreren Zeigern in jedem Knoten folgt, die den Knoten mit dem Rest der Datenstruktur verbinden. Wenn sie den Knoten durchquert, extrahiert die Strukturabarbeitungsvorrichtung 27 die Anweisungen und die Daten und sendet diese die Graphik-Pipeline nach unten, wo sie möglicherweise zu einer Anzeige des durch die Datenstruktur definierten Objektes führen.
Die Datenstruktur liegt in einer Graphikumgebung vor, die durch einen Graphikkontext definiert ist, der im folgenden genauer beschrieben wird. Der Graphikkontext ist über einen virtuellen Stammknoten mit der Systemdatenstruktur verbunden. Ein virtueller Stammknoten ist einfach der vom Benutzer erzeugte oberste Knoten, der vom Graphikkontext abstammt, der vom System erzeugt worden ist, wie in Fig. 13 gezeigt ist.
Während des Aufbaus einer Datenstruktur bieten die Knoten, die die Datenstruktur bilden, einen weiten Bereich von Funktionen, d. h. von beschreibenden Graphikprimitiven, zur Steuerung des Durchquerungsflusses. Die Knoten werden in Gruppen oder Strukturen zusammengefaßt, indem zuerst die Strukturgraphikroutine (SGR) aufgerufen wird:
SGR$BEGIN_STRUCTURE (context);
und anschließend die Routinen aufgerufen werden, die den Knoten erzeugen, woraufhin die Sequenz mit der Routine SGR$END_STRUCTURE (context, handle) beendet wird. Dies führt dazu, daß die Zeiger die Knoten zusammenbinden, so daß der Strukturabarbeitungsvorrichtung 27 ermöglicht wird, die Knoten in ihrer korrekten Reihenfolge zu durchqueren, wie im folgenden beschrieben wird.
Es gibt sechs Knotenklassifikationen zur Erzeugung von Datenstrukturen. Die ersten drei sind:
Primitivknoten - enthalten Graphikdaten für Vektoren, Polygone und Zeichenketten.
Attributknoten - steuern das Erscheinungsbild der Graphikprimitive wie z. B. die Linienfarbe, das Linienmuster, die Schattierung und die Helligkeit.
Transformationsknoten - beschreiben, wie Daten auf dem Bildschirm angezeigt werden. Transformationsknoten steuern die Zusammensetzung von Matrizen für eine Graphiktransformation und eine Normaltransformation sowie für den Arbeitsbereich. Wenn z. B. ein Primitivknoten einen Würfel bildet, kann ein Transformationsknoten diesen skalieren und drehen, um einen Mauerstein zu erzeugen.
Die nächsten drei Knoten werden verwendet, um weiterentwickelte Graphikdatenstrukturen zu erzeugen.

REFERENZKNOTEN

Hierarchische Strukturen werden mit Referenzknoten aufgebaut. Ein Referenzknoten weist die Strukturabarbeitungsvorrichtung 27 an, eine weitere Struktur (als "Unterstruktur" der aufrufenden Struktur bezeichnet) zu durchqueren, bevor die Durchquerung der Struktur, die den Referenzknoten enthält, fortgesetzt wird. Referenzknoten operieren in drei Betriebsarten: Wiederherstellung, Nichtwiederherstellung und Verzweigung. Der ref_ mode-Parameter der Routine, die den Knoten erzeugt, definiert die Betriebsart. Diese Betriebsarten steuern die Art, in der Veränderungen des hierarchischen Graphikzustands die Durchquerung anderer Abschnitte der Graphikdatenstruktur beeinflussen.

Wiederherstellungsbetriebsart

Ein auf die Wiederherstellungsbetriebsart eingestellter Referenzknoten weist die Strukturabarbeitungsvorrichtung 27 an, den aktuellen Graphikzustand wie z. B. die aktuelle Transformationsmatrix, die aktuellen Attributeinstellungen usw. auf einem Stapel zu speichern, bevor die bezeichnete Unterstruktur durchquert wird, und anschließend diesen Zustand wiederherzustellen, wenn sie die Durchquerung der Unterstruktur abgeschlossen hat. Somit beeinflussen die Veränderungen des hierarchischen Graphikzustands, die in einer Unterstruktur vorgenommen werden, nicht den Graphikzustand höherer Strukturen.

Nichtwiederherstellungsbetriebsart

Ein auf diese Nichtwiederherstellungsbetriebsart eingestellter Referenzknoten leitet die Strukturabarbeitungsvorrichtung 27 um, weist jedoch die Strukturabarbeitungsvorrichtung nicht an, den hierarchischen Graphikzustand zu speichern und nach Rückkehr zum Referenzknoten wiederherzustellen. Diese Betriebsart ist in wenigstens zwei Situationen nützlich: wenn sicher ist, daß eine bezeichnete Unterstruktur den Graphikzustand nicht verändern wird, und die Durchquerungsleistung optimiert werden soll, und wenn Veränderungen des Graphikzustands in niedrigeren hierarchischen Ebenen die Durchquerung einer gleichen oder höheren Ebene der Datenstruktur beeinflussen sollen.

Verzweigungsmodus

Wie bei der Wiederherstellungs- und Nichtwiederherstellungsbetriebsart leitet ein auf die Verzweigungsbetriebsart eingestellter Referenzknoten die Durchquerung durch die Strukturabarbeitungsvorrichtung um. Wenn jedoch die Strukturabarbeitungsvorrichtung 27 die Durchquerung der bezeichneten Unterstruktur beendet, kehrt sie nicht zum Referenzknoten zurück; somit ist es nicht erforderlich, den Graphikzustand zu speichern oder wiederherzustellen. Die Verzweigungsreferenzbetriebsart wird üblicherweise mit bedingten Referenzknoten verwendet, die zwischen zwei oder mehr Unterstrukturen auswählen. Sie ähnelt der "GOTO"-Anweisung in einer Programmiersprache.
Es gibt zwei Typen von Referenzknoten: bedingte und unbedingte. Beide Knotentypen können Wiederherstellungs-, Nichtwiederherstellungs- und Verzweigungsreferenzen ausführen. Bedingte Knoten wählen in Abhängigkeit vom Wert eines oder zweier Operanden einen von zwei oder mehr alternativen Durchquerungspfaden aus. Zum Beispiel vergleicht ein Typ eines bedingten Knotens, ob ein Operand gleich, größer oder kleiner als der andere ist. Unbedingte Knoten bezeichnen eine einzelne Unterstruktur mit der Option der Rückkehr zur Struktur auf höhere Ebene, wenn die Strukturabarbeitungsvorrichtüng 27 die Durchquerung der bezeichneten Struktur beendet. Die Fig. 14a-c bezeichnen Beispiele verschiedener Arten von Referenzen. Es ist zu beachten, daß ein "R", "NR" oder "B" auf der rechten Seiten eines Referenzknotens in den Fig. 14a-c anzeigt, ob die Referenz eine Wiederherstellungs-, Nichtwiederherstellungs- oder Verzweigungsvariante ist. Außerdem ist am Hauptreferenzzeiger für Nichtwiederherstellungs-Referenzen als zusätzliche visuelle Verdeütlichung ein Kreis angeordnet, wobei die Knoten, die auf eine Verzweigungsreferenz folgen, grau schattiert sind, um zu zeigen, daß die Strukturabarbeitungsvorrichtung 27 diese Knoten nicht durchquert.
Fig. 14a zeigt eine Datenstruktur, die einen Aufruf/Wiederherstellungs-Knoten kennzeichnet, der einen roten Kreis mit einem blauen Quadrat anzeigt. Da der Referenzknoten den Zustand wiederherstellt, beeinflußt das Rote-Linienfarbe-Attribut nicht das in der aufrufenden Struktur gesetzte Linienfarbe-Attribut.
Fig. 14b zeigt eine Datenstruktur, die einen bedingten Prüf/Nichtwiederherstellungs-Knoten kennzeichnet, der entweder ein blaues oder ein rotes Quadrat anzeigt, in Abhängigkeit davon, ob der vom Prüfungs/Nichtwiederherstellungs-Knoten geprüfte Operand wahr oder falsch ist. Da der Referenzknoten den Zustand nicht wiederherstellt, beeinflußt das in der bezeichneten Struktur gesetzte Linienfarbe-Attribut die von der aufrufenden Struktur angezeigte Farbe.
Fig. 14c zeigt eine Datenstruktur, die einen bedingten Vergleichs/Verzweigungs-Knoten kennzeichnet, der in Abhängigkeit von den Werten der Operanden, die vom Vergleichs/Verzweigungs-Knoten verglichen werden, eine von drei bezeichneten Unterstrukturen anzeigt. Es ist zu beachten, daß Diagramme der Unterstrukturen, die nicht auf die Seite passen, durch etikettierte Rahmen dargestellt sind.

Zuweisungsknoten

Die Zuweisungsknoten richten die Werte (Operanden), die von bedingten Referenzknoten geprüft werden, ein und manipulieren diese, wodurch eine dynamische Kontrolle darüber ermöglicht wird, wie ein gegebener bedingter Referenzknoten den Durchquerungspfad auswählt. Die Knoten führen mit den in den Strukturspeicherstellen enthaltenen Daten Operationen durch. Die Operationen umfassen Verschieben, logisches ODER (Bits setzen), logisches NICHT- UND (Bits löschen), Addieren, Subtrahieren, logisches EXKLUSIV-ODER.

Spezialknoten

Die Spezialknoten ermöglichen den Aufbau von kundenspezifischen Knoten, die Verwendung der gleichen Daten an verschiedenen Stellen in der Struktur und das Speichern unbenutzter Daten. Dies spart sowohl Strukturspeicherplatz als auch Bearbeitungszeit. Es sind drei Spezialknoten vorgesehen. Ein Datenknoten, ein Auswahiknoten sowie ein Indirektknoten. Diese Knoten können eine erhöhte Flexibilität schaffen, indem sie der Anwendung erlauben, eine Datenstruktur nach ihrem eigenen Bedarf zu erstellen.
Datenknoten enthalten Anwendungsdaten in Feldern, die für die Anwendung reserviert sind. Die Strukturabarbeitungsvorrichtung ignoriert Daten in den Datenknoten und folgt den next-Zeigern.
Der Auswahiknoten enthält Anweisungen und Daten, die zur Pipeline weitergeleitet werden. Die Strukturabarbeitungsvorrichtung 27 verarbeitet die Införmationen in einem Auswahiknoten nicht, leitet jedoch diesen Knoten an das Graphikuntersystem 27 weiter, ohne Veränderungen des Untersystemzustands aufzuzeichnen. Auswahiknoten können den Zustand des Graphikuntersystems verändern, wobei jedoch die Strukturabarbeitungsvorrichtung die auf diese Weise vorgenommenen Veränderungen nicht rückgängig macht.
Der Indirektknoten schafft die Fähigkeit, auf die Daten in einem Knoten ausgehend von einem weiteren Knoten in der Datenstruktur Bezug zu nehmen. Zum Beispiel kann eine Anwendung einen Knoten definieren, der Linienfarbe-Daten enthält, und Indirekt-Knoten verwenden, um im Indirekt- Knoten auf die Informationen Bezug zu nehmen. Dies spart Speicher und ermöglicht Veränderungen der Farbdefinitionen, ohne viele über die Struktur verteilte Knoten zu bearbeiten. Jede Primitiv-, Attribut- und Transformationsoperation kann unter Verwendung von Indirekt-Knoten ausgeführt werden.
Fortschrittliche Graphikdatenstrukturen werden von den in Tabelle 1 gezeigten Routinen erzeugt. Tabelle 1: fortschrittliche Graphikdatenstruktur-Routinen
Die Verwendung bedingter Knoten bietet dem Benutzer eine größere Flexibilität bei der Erzeugung fortschrittlicher Datenstrukturen. Wie in Tabelle 2 gezeigt, werden bedingte Knoten erzeugt, indem die Zuweisungsknoten-Routinen 4 bis 9 von den Routinen 10 bis 17 und die Spezialknoten von den Routinen 18 bis 21 aufgerufen werden.

Bedingte Referenzknoten

Bedingte Referenzknoten leiten den Durchquerungspfad der Strukturabarbeitungsvorrichtung 27 entweder auf der Grundlage einer Wahr/Falsch-Prüfung oder eines Wertevergleichs um. Auf der Grundlage des Ergebnisses der Prüfung weist der bedingte Referenzknoten die Strukturabarbeitungsvorrichtung 27 an, einem vorgegebenen Durchquerungspfad zu folgen, der dem Prüfergebnis zugeordnet ist.
Die von den bedingten Referenzknoten ausgeführte Prüfung verwendet Werte, die in einem oder zwei Operanden (in Abhängigkeit vom Knotentyp) im Knoten gespeichert sind. Die Werte dieser Operanden werden durch die Manipulationen der Zuweisungsknoten bestimmt, wodurch eine dynamische Kontrolle darüber ermöglicht wird, wie ein gegebener bedingter Referenzknoten den Durchquerungspfad auswählt. Diese Operanden werden unter Verwendung der in Tabelle 2 beschriebenen vier Zugriffsarten wiedergewonnen, die Gegenstand der vorliegenden Erfindung sind.
Die Zugriffsarten sind durch Konstanten spezifiziert, die in den Parametern mode, mode1 oder mode2 (in Abhängigkeit vom Knotentyp) der Routine, die den Knoten erzeugt, festgelegt. Die Zugriffsarten teilen dem System mit, wie die Operationsspezifizierer-(opspec)-Parameterargumente der Routine zu interpretieren sind. Der model-Parameter spezifiziert den Zugriff auf opspec1, während mode2 den Zugriff auf opspec2 spezifiziert. Tabelle 2: Operanden-Zugriffsmodi
Die vom bedingten Referenzknoten durchgeführte Prüfung verwendet den Wert des Operanden zum Zeitpunkt der Durchquerung; dies kann der an die Knotenbildungsroutine bei deren Aufruf weitergeleitete Operand sein, oder ein Zuweisungsknoten kann den Wert des Operand verändert haben, wie im folgenden genau beschrieben wird.
Die Operandenzugriffsmodi spielen bei der Verwendung von Zuweisungs- und Referenzknoten eine wichtige Rolle. Durch Verwendung der Zugriffsmodi können Zuweisungsknoten Zusatzdaten oder allgemeine Daten im Strukturspeicher erzeugen. Der Referenzknoten kann dann dazu veranlaßt werden, in Abhängigkeit von den erzeugten Daten zu verzweigen. Die Verwendung von Spezialknoten erlaubt, die Daten an das Graphikuntersystem 17 zu senden. Auf diese Weise kann die Datenstruktur quasi ein "Unterprogramm" schreiben dieses während der Durchquerung der Struktur ausführen. Dies ermöglicht eine allgemeinere Funktionalität sowie eine effizientere Verwendung der Speicherbetriebsmittel als herkömmliche Verfahren, wobei eine bedingte Verzweigung an einer festen Stelle wie z. B. einem Bedingungsregister stattfindet.
Beispiele für bedingte Referenz- und Zuweisungsknoten sind folgende:
Der test-Knoten wird mit folgender Routine erzeugt:

SGR$TEST (context, reference_mode, mode, opspec, true_handle, false_handle, handle)

Dieser Knoten führt eine einfache Wahr/Falsch-Prüfung für einen Operanden aus und leitet die Strukturabarbeitungsvorrichtung um, um in Abhängigkeit davon, ob die Ergebnisse der Prüfung wahr (ungleich 0) oder falsch (gleich 0) sind, eine von zwei Unterstrukturen zu durchqueren. Der Wert des Operanden bleibt unverändert.
Der test_and clear-Knoten wird mit folgender Routine erzeugt:

SGR$TEST_AND_CLEAR (context, reference_mode, mode, opspec, true_handle, false_handle, handle)

Dieser Knoten führt eine Wahr/Falsch-Prüfung ähnlich dem Prüf-Knoten durch. Er prüft zuerst den Wert eines Operanden, und setzt anschließend den Wert des Operanden auf 0 (falsch). Da er den Operanden löscht (d. h. er setzt ihn auf eine Falsch-Bedingung), wird dieser Knoten bei einer anschließenden Durchquerung die Strukturabarbeitungsvorrichtung 27 nur dann auf den Pfad leiten, der einer Wahr- Bedingung zugeordnet ist, wenn der Operand erneut auf wahr zurückgesetzt worden ist.
Der compare-Knoten wird mit folgender Routine erzeugt:

SGR$COMPARE (context, reference_mode, mode1, opspec1, mode2, opspec2, less_handle, equal handle, greater_handle, handle)

Dieser Knoten führt eine Prüfung von zwei Operanden durch, um zu bestimmen, welcher, falls überhaupt, größer ist, und leitet die Strukturabarbeitungsvorrichtung um, um in Abhängigkeit davon, ob der erste Operand kleiner, gleich oder größer als der zweite Operand ist, eine von drei Unterstrukturen zu durchqueren. Die Operanden bleiben unverändert.
Der case-Knoten wird mit folgender Routine erzeugt:

SGR$CASE (context, reference_mode, mode, opspec, count, otherwise_handle, case_handles, handle)

Dieser Knoten prüft den Wert eines Operanden und leitet die Strukturabarbeitungsvorrichtung um, um eine Unterstruktur zu durchqueren, die diesem Wert zugeordnet ist; wenn der Wert des Operanden keiner Unterstruktur zugeordnet ist, wird eine Vorgabe-Unterstruktur durchquert. Der Operand bleibt unverändert. Dieser Knoten erlaubt die Auswahl mehrerer Durchquerungspfade in Abhängigkeit vom Wert des Operanden im Knoten.
Die test_set- und test_dear-Knoten werden mit folgender Routine erzeugt:

SGR$TEST_SET (context, reference_mode, mode1, opspec1, mode2, opspec2, true_handle, false_handle, handle)

SGR$TEST_CLEAR (context, reference_mode, mode1, opsepec1, mode2, opspec2, true_handle, false_handle, handle)

Diese Knoten erlauben die Durchführung maskenähnlicher Prüfungen, um zu bestimmen, welche Teile der Graphikdatenstruktur durchquert werden. Der test_set-Knoten bestimmt, ob die Bits, die im ersten Operanden gesetzt sind, auch im zweiten Operanden gesetzt sind. Wenn das Prüfungsergebnis wahr ist (d. h., die logische UND-Verknüpfung der zwei Operanden ist gleich dem ersten Operanden), dann wird die erste Unterstruktur durchquert; ist es falsch, wird die zweite Unterstruktur durchquert.
Der test_dear-Knoten bestimmt, ob die Bits, die im ersten Operanden gelöscht sind, auch im zweiten Operanden gelöscht sind. Wenn das Prüfungsergebnis wahr ist (d. h., wenn die logische UND-Verknüpfung der zwei Operanden gleich 0 ist), dann wird die erste Unterstruktur durchquert; ist es falsch, wird die zweite Unterstruktur durchquert.
Zum Beispiel könnte im Register 1 eine Maske gespeichert sein, die angibt, ob bestimmte Merkmale "freigegeben" oder "gesperrt" sind. Ein test_set-Knoten könnte verwendet werden, um zu prüfen, ob ein Merkmal freigegeben wurde, und könnte, falls dem so ist, die Strukturabarbeitungsvorrichtung umleiten, um die passende Unterstruktur zu durchqueren.

Zuweisungsknoten

Zuweisungsknoten schaffen zusätzliche Flexibilität bei der Verwendung bedingter Referenzknoten, indem sie als Ergebnis der Datenstrukturdurchquerung deren Operanden modifizieren. Mit anderen Worten, die von den bedingten Referenzknoten zu prüfende Bedingung kann bei jeder Durchquerung in Abhängigkeit davon, wie Zuweisungsknoten verwendet werden, um deren Operanden zu modifizieren, unterschiedlich sein.
Zuweisungsknoten führen arithmetische Operationen oder Bit-Operationen mit den von den bedingten Referenzknoten verwendeten Operanden durch. Folgendes sind Zuweisungsknoten:
Der move-Knoten wird mit folgender Routine erzeugt:

SGR$MOVE (context, mode1, opspec1, mode2, opspec2, handle)

Dieser Knoten führt eine Langwort-Verschiebungsoperation von der durch opspec1 beschriebenen Stelle zu der durch opspec2 beschriebenen Stelle aus.
Der move_block-Knoten wird mit folgender Routine erzeugt:

SGR$MOVE_BLOCK (context, size, mode1, opspec1, mode2, opspec2, handle)

Dieser Knoten führt eine Verschiebungsoperation für einen Block von Langwörtern, der durch den size-Parameter angegeben ist, von der durch opspec1 beschriebenen Stelle zu der durch opspec2 beschriebenen Stelle aus.
Der move mask-Knoten wird mit folgender Routine erzeugt:

SGR$MOVE_MASK (context, mask, mode2, opspec2, handle)

Dieser Knoten setzt die durch den mask-Parameter spezifizierten Bits im zweiten Operanden auf die gleichen Werte wie die entsprechenden Werte im ersten Operanden.
Der set_Bits-Knoten wird mit folgender Routine erzeugt:

SGR$SET_BITS (context, mode1, opspec1, mode2, opspec2, handle)

Dieser Knoten führt eine logische ODER-Operation aus, wobei alle die Bits im zweiten Operanden gesetzt werden, die im ersten Operanden gesetzt sind.
Der dear_bits-Knoten wird mit folgender Routine erzeugt:

SGR$CLEAR_BITS (context, mode1, opspec1, mode2, opspec2, handle)

Dieser Knoten führt eine logische NICHT-UND-Operation aus, wobei all jene Bits im zweiten Operanden gelöscht werden, die im ersten Operanden gesetzt sind.
Der add-Knoten wird mit folgender Routine erzeugt:

SGR$ADD (context, mode1, opspec1, mode2, opspec2, handle)

Dieser Knoten führt eine vorzeichenbehaftete Langwort-Addition mit dem Operanden 1 und dem Operanden 2 aus. Das Ergebnis der Addition wird im zweiten Operanden gespeichert.
Der sub-Knoten wird mit folgender Routine erzeugt:

SGR$SUB (context, mode1, opspec1, mode2, opspec2, handle)

Dieser Knoten führt eine vorzeichenbehaftete Langwort- Subtraktion aus, wobei Operand 1 von Operand 2 subtrahiert wird und das Ergebnis im zweiten Operanden gespeichert wird.
Der xor-Knoten wird mit folgender Routine erzeugt:

SGR$XOR (context, mode1, opspec1, mode2, opspec2, handle)

Dieser Knoten führt eine logische EXKLUSIV-ODER-Operation unter Verwendung der zwei Operanden aus und speichert das Ergebnis im zweiten Operanden. Es ist zu beachten, daß dann, wenn alle Bits im zweiten Operanden gesetzt sind, eine logische NICHT-Verknüpfung ausgeführt wird.
Im folgenden sind Beispiele von Spezialknoten dargestellt.
Die Routinen, die Spezialknoten aufbauen, erhöhen die Flexibilität und Effizienz der Graphikdatenstruktur. Es gibt folgende drei Knoten:
Der generic-Knoten wird mit folgender Routine erzeugt:

SGR$GENERIC (context, size, data, handle)

Der genric-Knoten schafft die Mittel zum Senden von Anweisungen oder Daten oder beidem durch die Graphikpipeline; er erzeugt quasi einen kundenspezifischen Knoten.
Die verwendeten Anweisungen sollten den hierarchischen Graphikzustand nicht beeinflussen.
Der indirect-Knoten wird mit folgender Routine erzeugt:

SGR$INDIRECT (context, to_handle, handle)

Der indirect-Knoten bezieht sich auf Daten in einem weiteren Knoten. Eine Anwendung kann indirect-Knoten einsetzen, die sich auf vordefinierte Daten beziehen. Die Routine setzt den Knotentyp des bezeichneten Knotens sowie einen Zeiger, der die Strukturabarbeitungsvorrichtung umleitet, um die in diesem Knoten enthaltenen Daten zu durchqueren, in den zu erzeugenden indirect-Knoten ein. Dies erzeugt einen Knoten, der mit dem bezeichneten Knoten identisch ist, jedoch in einem anderen Abschnitt der Graphikdatenstruktur angeordnet ist. Diese Routine ist beim Aufbau von Attributtabellen nützlich. Dies spart Speicher und begrenzt die Anzahl der Veränderungen bei der Bearbeitung.
Der data-Knoten wird mit folgender Routine erzeugt:

SGR$DATA (context, size, data, handle)

Der data-Knoten wird zum Speichern oder Halten von Daten verwendet, die vom Anwendungsprogramm verwendet werden sollen. Während der Strukturdurchquerung läuft die Strukturabarbeitungsvorrichtung 27 über die Daten in diesem Knoten hinweg, folgt jedoch dem next-Zeiger.
Die Hauptfunktion der Strukturabarbeitungsvorrichtung 27 ist, die Knoten der Datenstrukturen genau in der geeigneten Reihenfolge zu durchqueren und jeden Knotentyp korrekt zu verarbeiten. Die Verarbeitungsfunktion der Strukturabarbeitungsvorrichtung 27 verwendet die Ausführung von Knotenanweisungen, die sich auf eine weitere Durch querung von Knoten der Struktur oder auf die bedingte Verzweigung zu alternativen Knotenästen in der Knotenstruktur beziehen, und das Senden der Daten und Anweisungsinformationen, die in den durchquerten Knoten enthalten sind, zum Graphik-Pipelineprozessor 29, um diese wie oben beschrieben zu verarbeiten.

Software-Organisation

In Fig. 3 ist ein Blockschaltbild der Software-Organisation des Graphiksystems der Erfindung dargestellt. Eine Anwendung 100 enthält Anforderungen, die sich auf den Aufbau von Graphikdatenstrukturen beziehen. In der Host- Zentraleinheit 10 sind viele Anwendungen 100 präsent, um mehrere Graphikdatenstrukturen für die Manipulation und Anzeige durch das Graphikuntersystem 17 aufzubauen. In der bevorzugten Ausführungsform ist das X-Window-System implementiert, um die Fenster- und Bitraster-Graphikanforderungen auszuführen, die im Anwendungsprogramm 100 enthalten sind. Das X-Window-System ist in Publikationen vollständig beschrieben, die vom Massachusetts Institute of Technology herausgegeben werden, wie z. B. Xlib - C Language X Interface Protokoll Version 11 von Jim Gettys, Ron Newman und Robert W. Scheifler, und X Window System Protokoll, Version 11 Beta Test von Robert W. Scheifler. Diese Publikationen sind frei verfügbar und können für jeden beliebigen Zweck ohne Gebühr verwendet, kopiert, modifiziert und verteilt werden. Informationen über das X-Window-System können vom Massachusetts Institute of Technology Laboratory for Computer Science, 545 Technology Square, Cambridge, Massachusetts 02139 erhalten werden.
Das X-Window-System basiert auf einem Requester-Server- Modell. Die Anwendung 100 ist der Requester, der seine Arbeit verrichtet, indem er seine Anforderungen an einen Server-Prozeß 101 richtet. Der Server 101 führt die angeforderten Funktionen aus und gibt an die Requester-Anwendung 100 einen Status zurück. Die Hauptkomponenten des X- Window-System sind ein X-Protokoll 102, der Server 101 und ein XLib-103.
Das X-Protokoll 102 definiert ein Modell für die Kommunikation zwischen einem Server 101 und einem Requester 100, und definiert ferner das Modell für das Graphikuntersystem 17. Das Modell besteht aus mehreren Objekten, die auf bestimmte Weise wechselwirken. Das grundlegendste Objekt ist das Fenster, eine rechtwinklige Matrix von Pixeln, die zu einem gegebenen Zeitpunkt auf dem Monitor 38 (teilweise) sichtbar sein können oder nicht. Die Fenster unterliegen einer Hierarchie: mit anderen Worten, Fenster können Unterfenster besitzen. Wenn ein Unterfenster angezeigt wird, wird es durch sein Stammfenster gekappt. Der Monitor ist der Stamm der Hierarchie. Jedes Fenster besitzt eine einzigartige ID und eine optionale Eigenschaftsliste und kann von einem Prozeß 100 manipuliert werden, der nicht der Erzeugerprozeß 100 ist. Das X-Protokoll 102 gibt weder Beschränkungen für die Anzahl der bestehenden Fenster vor, noch fördert es diese Beschränkungen (d. h. Fenster sind "billig"). Andere Objekte, die durch das X-Protokoll 102 definiert sind, umfassen
- Farben-Abbildungen: Beziehungen zwischen Pixelwerten und Farben
- Pixel-Abbildungen: eine rechteckige Matrix von Fixeln
- Kacheln: eine spezielle Art einer pixmap, die zum Füllen von Bereichen verwendet wird und Cursor definiert
- Polylinien: ein Satz zusammenhängender Punkte, die in einem Fenster gemäß spezifizierten Kriterien angezeigt werden
- (Glyph)-Zeichensätze: ein Satz von Bitmustern, die alphanumerischen Zeichen zugeordnet sind (einschließlich proportionaler Zeichensätze)
Das X-Protokoll 102 definiert ferner mehrere Ereignisse. Diese Ereignisse werden vom Server 101 erfaßt, wenn z. B. über den Steuerprozessor 13 und den Peripherieverstärkerkasten 23 (siehe Fig. 3) Eingaben von Peripheriegeräten empfangen und an die Requester 100 weitergeleitet werden. Beispiele für Ereignisse sind
- Freilegungsereignisse: Teile eines angezeigten Fensters, die vorher überdeckt waren, wurden nun freigelegt
- Tastaturereignisse: eine Taste auf der Anzeigevorrichtung wurde gedrückt
- Druckknopfereignisse: ein Druckknopf auf einer Zeigevorrichtung (z. B. der Maus 20) wurde gedrückt.
Die Requester 100 empfangen nur Benachrichtigungen über Ereignisse, an denen sie ausdrückliches Interesse besitzen. Ereignisse werden in einer zeitlich geordneten Warteschlange gehalten und können von Requestern 100 entweder synchron oder asynchron empfangen werden.
Der X-Server 100 vermittelt die Kommunikation zwischen Requester-Anwendungen 100 und dem Graphikuntersystem 17. Jeder Requester 100 richtet über ein Kommunikationsprotokoll eine Verbindung zum Server 101 ein. Ein Requester 100 sendet Anweisungen an einen Server 101, um Funktionen, wie z. B. Zeichnen in ein Fenster, Laden von Zeichensätzen, Manipulieren der Farben-Abbildung, Bekunden von Interesse an bestimmten Ereignissen usw., auszuführen. Der X-Server 101 wird dann die angeforderten Funktionen ausführen, indem er z. B. über einen Knoten im Strukturspeicher 26 Anweisungen an das Graphikuntersystem sendet.
Ein Server 101 ist immer auf der gleichen Maschine wie der Monitor 38 angeordnet. Es ist somit möglich, daß mehr als ein Server pro Maschine vorhanden ist, wobei ein Server mehr als einen Monitor 38 steuern kann. Jeder Monitor 38 kann jedoch von maximal einem Server gesteuert werden.
Der Server 101 erzeugt ein geräteunabhängiges (DDI) Programm, das für die Kommunikation vom X-Window-System zum spezifischen System der Erfindung, aus dem das Fenstersystem betrieben wird, mit einem geräteabhängigen (DDX) Programm verbunden ist. Im Hinblick auf die vorliegende Erfindung sind das bedeutendste Merkmal des DDX die dreidimensionalen Anzeigekontextfunktionen der Durchquerungssteuerung, die durch einen Anzeigeverwalter 106 im Fenster-Server 101 implementiert sind, um ein von einer Requester-Anwendung 100 definiertes Fenster mit der von der Requester-Anwendung 100 im Strukturspeicher 26 äufgebauten dreidimensionalen Graphikstruktur zu verbinden, wie offensichtlich ist. Auf diese Weise wird dem X-Window-System eine dreidimensionale Funktionalität verliehen.
Xlib 103 ist die Schnittstelle des Requesters zu einem X- Server. Sie ist eine verfahrensorientierte Schnittstelle, die den Funktionen entspricht, die vom darunterliegenden X-Protokoll 102 geschaffen werden. Daher gibt es Aufrufe, um Fenster zu erzeugen und in diese zu zeichnen usw. Da Xlib eine verfahrensorientierte Schnittstelle ist, ist sie dafür ausgelegt, von höheren Sprachen aufgerufen zu werden.
Ein Fensterverwalter 104 ist eine Anwendung, die eine Mensch-Arbeitsplatz-Schnittstelle implementiert. Sie ermöglicht einem Benutzer typischerweise, Fenster zu erzeugen, zu verschieben, in der Größe zu verändern, in Symbole umzuwandeln und zu vernichten. Diese Aktionen werden unter Verwendung der Maus 20 als Zeigegerät in Verbindung mit Druckknopfklicks und Tastaturanschlägen angewiesen. Obwohl das X-Protokoll 102 keinen Fensterverwalter spezifiziert, kann derzeit unter verschiedenen gewählt werden. Das X-Protokoll bietet die für eine Implementierung eines kundenspezifischen Fensterverwalters erforderlichen Merkmale. Dies bedeutet, daß kein Fensterverwalter notwendig ist, um X-Anwendungen laufen zu lassen, wobei es möglich ist, mehrere Fensterverwalter zu besitzen (jedoch nicht gleichzeitig auf der gleichen Anzeigevorrichtung).
Dem X-Window-System kann ein Graphik-Softwarepaket wie z. B. ein GKS-o/b-Softwarepaket überlagert sein. In der vorliegenden Erfindung wird ein Graphik-Softwarepaket für zweidimensionale Anzeigen mittels Bitrastergraphik verwendet. Das X-Window-System wurde tatsächlich für die Verwendung in Verbindung mit Bitraster-Graphiksystemen entwickelt. Die Bitraster-Graphik-Kontexte und Anweisungswarteschlangen werden vom Wiedergabeprozessor 36 verarbeitet, wie offensichtlich ist.
Gemäß der Erfindung werden dreidimensionale Graphikdatenstrukturen von den Anwendungs-Requestern 100 direkt mittels strukturierter Graphikroutinen 105 (SGR) aufgebaut, die im Host-Untersystem zur Verfügung gestellt werden. Die Anwendungen 100 verwenden die verschiedenen strukturierten Graphikroutinen 105 nach Bedarf, um spezifische Graphikdatenstrukturen aufzubauen. Die strukturierten Graphikroutinen führen Routinenanforderungen aus, die von der Anwendung 100 gestellt werden, und bauen geeignete verbundene Knoten im Strukturspeicher 26 auf.
Es folgen mehrere Beispiele strukturierter Graphikroutinen, die im Host-Untersystem zur Implementierung von Graphikdatenstrukturen vorgesehen sein können.

Beispiel 1:

SGR$BEGIN_STRUCTURE

FORMAT

SGR$BEGIN_STRUCTURE (context)

ARGUMENTE

context

Der Identifizierer des Graphikkontextes für diesen Unterroutinenaufruf. Das context-Argument ist die Adresse einer vorzeichenlosen ganzen Zahl, die den Identifizierer des Graphikkontextblocks enthält.

ZWECK

Eine Struktur zu beginnen.

BESCHREIBUNG

Eine Struktur ist eine Gruppe von miteinander verbundenen Knoten. Nach dem Aufruf von SGR$BEGIN_STRUCTURE werden alle mit dem gleichen Kontext erzeugten Knoten an das Ende der Struktur angefügt. Durch SGR$BEGIN_STRUCTURE werden keine Knoten erzeugt. Eine Struktur wird durch SGR$END_STRUCTURE abgeschlossen.
Die Informationen für die Verbindung der Knoten sind in dem Graphikkontext gespeichert, der durch das context-Argument bezeichnet ist, so daß es möglich ist, mehrere Strukturen gleichzeitig unter Verwendung mehrerer Kontexte aufzubauen.
Das Aufrufen von SGR$BEGIN_STRUCTURE für einen Kontext, der keine Struktur aufbaut, ist ein Fehler.
Es kann erwünscht sein, jede Struktur mit einem Knoten zu beginnen, der nichts tut, wie z. B. einem data-Knoten oder einem gesperrten Knoten. Dies ermöglicht, daß auf die Struktur von mehreren Knoten ausgehend Bezug genommen werden kann, und erlaubt noch die Ersetzung des ersten wirklichen Knotens in der Struktur.

Beispiel 2:

SGR$COLOR

FORMAT

SGR$COLOR (context, red, green, blue, color)

ARGUMENTE

context

red

Die Rotintensität der Farbe. Das red-Argument ist die Adresse eines vorzeichenlosen Langwortes im F_Fließformat, die den Wert für die Rotintensität enthält. Dieser Wert liegt im Bereich 0,0 (keine Intensität) bis 1,0 (volle Intensität).

green

Die Grünintensität der Farbe. Das green-Argument ist die Adresse eines vorzeichenlosen Langwortes im F_Fließformat, die den Wert für die Grünintensität enthält. Dieser Wert liegt im Bereich 0,0 (keine Intensität) bis 1,0 (volle Intensität).

blue

Die Blaumtensität der Farbe. Das blau-Argument ist die Adresse eines vorzeichenlosen Langwortes im F_Fließformat, die den Wert für die Blaumtensität enthält. Dieser Wert liegt im Bereich 0,0 (keine Intensität) bis 1,0 (volle Intensität).

color

Das von der Routine zurückgegebene Farb-Langwort. Das color-Argument gibt die Adresse eines vorzeichenlosen Lang worts zurück, das den Wert für die Farbe zurückgibt.

ZWECK

Erzeugen eines Farbwortes.

BESCHREIBUNG

Diese Routine erzeugt eine Farbe bestehend aus Rot-, Grün- und Blaumtensitäten. Das Format eines Farbwortes ist in der folgenden Skala gezeigt.
Die Farbe wird als Argument an SGR$SET_BACKGROUND, SGR$SET_LINE_COLOR, und SGR$STATUS weitergegeben.

Beispiel 3:

SGR$VECTOR

FORMAT

SGR$VECTOR (context, vertex_format, edit flags, count, vertex_array, handle)

ARGUMENTE

context

Der Identifizierer des Graphikkontextes für diesen Unterroutinenaufruf. Das Kontextargument ist die Adresse einer vorzeichenlosen ganzen Zahl, die den Identifizierer des Graphikkontextblocks enthält.

vertex_format

Merker, die das Format der vom vertex_array-Argument weitergeleiteten Scheitelpunkte deklarieren. Das vertex_format-Argument ist ein vorzeichenloses Langwort, das die folgenden Merker enthält:
Merker, die spezifizieren, wie die Routine die Statuswörter der aufgeschlüsselten Scheitelpunkte formatieren wird, wenn sie diese im Knoten speichert. Das edit_flags- Argument ist die Adresse eines vorzeichenlosen Langworts, das die folgenden Merker enthält:
Wenn im edit_flags-Argument weder DGR$M_EDIT_POLYLINE noch SGR$_M_EDIT_SEPERATE gesetzt ist, werden die Statuswörter der aufgeschlüsselten Scheitelpunkte nicht verändert, wobei für jeden Scheitelpunkt das Statuswort geeignet eingesetzt werden muß. Das edit_flags-Argument beeinflußt nicht die Scheitelpunkte ohne Statuswörter.

count

Die Anzahl der vom vertex_array-Argument weitergegebenen Scheitelpunkte. Das count-Argument ist die Adresse eines vorzeichenlosen Langworts.

vertex_array

Die Matrix der Scheitelpunkte, die die zu zeichnenden Vektoren definieren. Das vertex_array-Argument ist die Adresse. einer Matrix von Langwörtern; diese Matrix muß die Anzahl von Langwörtern enthalten, die gleich dem vom count-Argument weitergegebenen Wert multipliziert mit der Anzahl der Scheitelpunktkomponenten, die durch die Anzahl der in vertex_format gesetzten Merker angegeben wird, ist. Wenn z. B. vertex_format ein 3D-Breite-Status-Scheitelpunktformat deklariert, (indem im vertex_ format-Argument SGR$M_STATUS, SGR$M_X, SGR$M_Y und SGR$M_Z gesetzt sind) und daß count-Argument angibt, daß die Anzahl der Scheitelpunkte gleich 10 ist, dann muß die Scheitelpunktmatrix 40 Langwörter enthalten. Die Scheitelpunktkomponenten müssen in der Reihenfolge status, x, y, z, w vorliegen. Alle Koordinaten müssen das Vorgabe-Fließkommaformat aufweisen, das im Graphikkontext eingestellt ist.

handle

Der Identifizierer des von dieser Routine erzeugten Knotens. Das handle-Argument gibt die Adresse eines vorzeichenlosen Langworts zurück, das den Identifizierer enthält.

ZWECK

Erzeugen eines Vektorknotens.

BESCHREIBUNG

Diese Routine erzeugt einen Vektorknoten. Wenn dieser Knoten von der Strukturabarbeitungsvorrichtung 27 durchquert wird, werden die Daten an das Graphikuntersystem 17 weitergeleitet, um die anzuzeigenden Vektoren zu zeichnen, wie oben beschrieben worden ist. Damit die Vektoren sichtbar sind, müssen sie geeignet transformiert sein (z. B. müssen sie innerhalb der Kappungsebenen liegen), korrekte Attribute besitzen (wie z. B. eine Farbe, die sich von der Hintergrundfarbe unterscheidet) und dürfen nicht durch Polygone verdeckt sein.
Jeder Scheitelpunkt kann ein Statuswort und x-, y-, z- und w-Koordinaten besitzen. Das Statuswort setzt den Zeichenmodus und/oder gibt die aufgeschlüsselte Vektorfarbe frei.

Beispiel 4:

SGR$X_ROTATE MATRIX

FORMAT

SGR$X_ROTATE MATRIX (context, multiply_control, angle, matrix)

ARGUMENTE

context

multiply_control

Spezifiziert, wie das matrix-Argument zu interpretieren ist. Das multiply_control-Argument ist die Adresse eines vorzeichenlosen Langworts. Annehmbare Werte sind:

angle

Der Drehwinkel im Bogenmaß. Das angle-Argument ist die Adresse eines Langworts im F_Fließformat.

matrix

Die x-Rotationsmatrix, die von dieser Routine erzeugt wird. Das matrix-Argument gibt die Adresse einer 4x4-Matrix von Langwörtern im F_Fleißformat zurück, die die Ergebnismatrix enthalten. Die Matrix liegt in Zeilenhauptordnung vor.

ZWECK

Erzeugen einer x-Rotations-Matrix.

BESCHREIBUNG

Diese Routine berechnet eine Rotationsmatrix zum Drehen um die x-Achse. Die resultierende Rotation bewirkt in positiver x-Achsen-Richtung betrachtet eine Drehung im Uhrzeigersinn um angle im Bogenmaß. Die Rotationsmatrix wird im matrix-Argument zurückgegeben.
Im Host-Untersystem kann eine beliebige Anzahl zusätzlicher Routinen gespeichert sein, um einem Anwendungsprozeß 100 zu ermöglichen, eine verkettete Graphikdatenknotenstruktur aufzubauen, die ein dreidimensionales Bild in Farbe darstellt, um sie im Strukturspeicher 26 zu speichern und möglicherweise mittels der Strukturabarbeitungsvorrichtung 27 zu durchqueren. Es folgt ein Beispiel einer vollständigen Bibliothek strukturierter Graphikroutinen, wobei die Routinen nach Funktionen aufgelistet sind: Tabelle 1: SGR-Primitiv-Routinen Tabelle 2: SGR-Attribut-Routinen Tabelle 3: SGR-Wiedergabe-Routinen Tabelle 4: SGR-Transformations-Routinen Tabelle 5: SGR-Arbeitsbereich-Routinen Tabelle 6: SGR-Strukturaufbau-Routinen Tabelle 7: SGR-Referenz-Routinen Tabelle 8: SGR-Graphikkontext-Routinen Tabelle 9: SGR-Durchquerungssteuer-Routinen Tabelle 10: SGR-Picking-Routinen Tabelle 11: SGR-Eingangshandhabungs-Routinen Tabelle 12: SGR-Struktureditier-Routinen Tabelle 13: SGR-Strukturspeicher-Verwaltungs-Routinen Tabelle 14: SGR-Mehrzweck-Routinen
In Fig. 4 ist der Strukturspeicher 26 in Blockschaltbildform dargestellt. Die Hauptfunktion des Strukturspeichers ist, die "Arbeitskopie" der Graphikdatenstrukturen zu speichern, die von den in der Host-Zentraleinheit 10 residenten Anwendungsprogrammen 100 entweder mittels der strukturierten Graphikroutinen oder mittels des dem X- Window-System überlagerten Bitraster-Graphiksoftwarepakets aufgebaut worden sind. Der Speicher enthält eine Matrix von Speicherbausteinen 200, die mit jeweils einer minimalen Speichergröße von 1-MByte mittels 256k-CMOS- DRAMs implementiert sind. Die Matrix der Speicherbausteine 200 ist für insgesamt vier Megabyte Speicher ausgelegt. Es werden ein willkürlicher Zugriff, der 200 ns benötigt, und ein statischer Spaltenmodus verwendet, um einen sequentiellen Zugriff von 100 ns pro Wort zu erreichen.
Ein Strukturspeicherbus 201 verbindet die Speicherbausteine mit einer II32-Bus-Schnittstelle 202, einer Strukturabarbeitungsvorrichtungs-Schnittstelle 203 und einer Wiedergabeprozessor-Schnittstelle 204, um den Datenfluß zwischen den Speicherbausteinen 200 und der Host-Zentraleinheit 10 über den Steuerprozessor 13, den Wiedergabeprozessor 36 bzw. die Strukturabarbeitungsvorrichtung 27 zu bewerkstelligen. Die Strukturabarbeitungsvorrichtung 27 ist ein spezieller 32Bit-Bit-Slice-Prozessor, der so programmiert ist, daß er die dreidimensionalen Graphikdatenstrukturen durchquert, wie oben beschrieben worden ist. Für eine genauere Beschreibung der Komponenten des Strukturspeichers 26 und der Strukturabarbeitungsvorrichtung 27 des Graphikuntersystems 17 sollte auf Shadowfax Technical Manual, veröffentlicht von der Evans & Sutherland Computer Corporation, Bezug genommen werden.

Durchquerungssteuerung

Gemäß einer bedeutenden Lehre der Erfindung wird eine Durchquerungssteuerungsfunktion unter den Komponenten der Host- und Graphikuntersysteme aufgeteilt, um Anforderungen für Graphikstrukturdurchquerungen anzunehmen, die von mehreren konkurrierenden Anwendungsprogrammen 100, die in der Host-Zentraleinheit 10 resident sind, gestellt werden, und um anschließend solche Durchquerungsanforderungen einzuteilen und abzufertigen.
Die Durchquerungssteuerfunktionen sind in Form von Knotensteuerstrukturen ausgeführt, die im Strukturspeicher 26 aufgebaut sind und, wenn sie durchquert werden, einen Durchquerungsanforderungsmechanismus schaffen und die Durchquerungseinteilung, die Durchquerungsüberwachung und die Anwendungssynchronisierung handhaben. Die Steuerstrukturen dienen der Zuteilung des Graphikuntersystems 17 zur Abarbeitung der verschiedenen Anwendungsprogramme 100, die in der Zentraleinheit 10 resident sind, so daß jedes Programm das Graphikuntersystem als eigenes System betrachtet. Die Durchquerungssteuerstrukturen koordinieren somit die Durchquerungsanforderungen von den konkurrierenden Anwendungsprogrammen 100 mit der asynchronen Operation der Strukturabarbeitungsvorrichtung 27, um die Verarbeitungsleistung des Graphikuntersystems 17 zu maximieren und die Verarbeitung vieler Anwendungsprogrammen zu ermöglichen.
Gemäß der Erfindung gibt es drei grundlegende Durchquerungsstrukturen: eine Systemsteuerungsstruktur (SCS), dreidimensionale Anzeigekontexte (3DDCs) und dreidimensionale Graphikkontexte (3DGCs) Die Systemsteuerungsstruktur ist die Steuerung auf höchster Ebene für die Strukturabarbeitungsvorrichtung 27 und dient als Betriebssystem für die Strukturabarbeitungsvorrichtung 27. Die Anzeigekontexte definieren die Abbildung der dreidimensionalen Bilder innerhalb der Arbeitsbereiche auf dem Monitorbildschirm, die durch die Fenster definiert sind. Die Graphikkontexte stellen alle Graphikattribute und Steuerinformationen zur Verfügung, die zur Durchführung der Durchquerungen der Graphikdatenstrukturen erforderlich sind, einschließlich einer Verbindung zu einem komplementären Anzeige kontext.
Die Steuerstrukturen werden verbunden, indem eine doppelt verkettete Liste von Graphikkontexten, die von den Anwendungsprogrammen erzeugt werden, an die Systemsteuerungsstruktur angefügt wird. Jeder der Graphikkontexte in der Liste enthält einen Graphikkontext-Stammknoten, der zum Verbinden des Graphikkontextes mit einem Anzeigekontext verwendet wird, und einen virtuellen Stammknoten, der als Verbindung zu einer Graphikdatenstruktur verwendet wird (siehe Fig. 5). Die Anzeigekontexte können von mehreren Graphikkontexten gemeinsam benutzt werden, wodurch mehrere Graphikkontexte innerhalb eines einzigen Fensters operieren können. Außerdem kann ein Teil oder die gesamte Graphikdatenstruktur von mehreren Graphikkontexten gemeinsam genutzt werden.

SYSTEMSTEUERUNGSSTRUKTUR

Die Systemsteuerungsstruktur (SCS) dient als Ausführungsprogramm für die Strukturabarbeitungsvorrichtung 27, indem sie die folgenden Funktionen ausführt:
o sie erfaßt und akzeptiert Anforderungen für 3DGC- Durchquerungen.
o sie teilt alle 3DGC-Durchquerungen ein und fertigt diese ab.
o sie deaktiviert die 3DGCs und die 3DDCs, falls von der Durchquerungssteuerfunktion im Server 101 angefordert.

SCS-ERZEUGUNG UND STEUERUNG

Der Fensterserver 101 verwendet als einen Teil der DDX- Anlaufprozedur eine Durchquerungssteuerfunktion, um die Graphikdatenstrukturknoten zu belegen und zu erzeugen, die für die SCS-Struktur erforderlich sind, und um deren Durchquerung einzuleiten.
Ist die SCS gestartet, läuft sie weiter (d. h. sie wird durchquert) bis alle Durchquerungsanforderungen befriedigt worden sind. Wenn alle Anforderungen bedient worden sind, hält sich die SCS selbst an, indem sie den Steuerprozessor 13 auffordert, ihre Durchquerung beim nächsten Vertikalrücklauffortzusetzen, wodurch eine übermäßige SCS-Anforderungsverarbeitung verhindert wird. Nur unter den folgenden Ausnahmeumständen wird die SCS-Durchquerung beendet, was einen Neustart durch den Server 101 erfordert:
(a) der Server 101 erfaßt eine Durchquerungs-Zeitüberschreitungs-Bedingung.
(b) eine SCS-detektierte Fehlerbedingung wird erfaßt.
(c) der Server 101 hat die SCS-Durchquerung beendet, indem er als Teil der Server-Abschaltprozedur eine "Serverabschalt"-Anforderung ausgegeben hat.
(d) Die Strukturabarbeitungsvorrichtung 27 entdeckt eine Fehlerbedingung, wobei sie zu diesem Zeitpunkt anhält, nachdem sie den Steuerprozessor 13 benachrichtigt hat.

SCS-DATENBLOCK

Um ihre Funktion auszuführen, hält die SCS-Struktur eine Gruppe von Steuervariablen im Strukturspeicher 26, die gemeinsam als "SCS-Datenblock" bezeichnet werden. Die Inhalte dieses Datenblocks sind im folgenden beschrieben.

o SCS.State

Dieses Langwort zeigt den aktuellen Zustand der SCS- Ausführung, indem es einen der folgenden Werte annimmt:
SGR$$K_STATE_INITIAL - die SCS hat ihre Initialverarbeitung noch nicht abgeschlossen.
SGR$$K_STATE_UPDATE - die SCS führt eine SCS-Aktualisierungsverarbeitung aus.
SGR$$K_STATE_IDLE - die SCS hat sich selbst angehalten, nachdem sie keine anhängenden Durchquerungsanforderungen gefunden hat, und erwartet, beim nächsten Vertikalrücklauf vom Steuerprozessor 13 fortgesetzt zu werden.
SGR$$K_STATE_REQ_PHASE - die SCS führt eine Anforderungsverarbeitung aus.
SGR$$K_STATE_EVENT - die SCS hat dem Steuerprozessor 13 ein Ereignis präsentiert und erwartet, sofort fortgesetzt zu werden.
SGR$$K_STATE_TRAV_PHASE - die SCS führt eine Durchquerungsverarbeitung aus.
SGR$$K_STATE_RANDOWN - die SCS hat eine "Serverabschalt"-Anforderung verarbeitet.
SGR$$K_STATE_TRAV_UPDATE - die SCS führt SCS-zurückgestellte Aktualisierungen an der Graphikanzeigestruktur des Requesters durch.
SGR$$K_STATE TRAV CXT SETUP - die SCS führt eine 3DGC-Einstellverarbeitung aus.
SGR$$K_STATE_TRAV_CXT_CLEANUP - die SCS führt eine 3DGC-Aufräumverarbeitung aus.
SGR$$K_STATE_TRAV 3DDC - die 3DDC-Struktur wird durchquert.
SGR$$K_STATE_TRAV_CLIENT - die Graphikanzeigestruktur des Requesters 100 wird durchquert.
SGR$$K_STATE_INT_ERROR - die SCS hat sich selbst angehalten, nachdem sie einen internen Fehler erfaßt hat.
Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Frame_Bank

Dies ist ein systemweiter Langwortmerker, der anzeigt, welche Rahmenpufferbank angezeigt wird.
SGR$$K_BANK_A - Rahmenpufferbank "A" wird derzeit angezeigt.
SGR$$K_BANK_B - Rahmenpufferbank "B" wird derzeit angezeigt.
Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.WLUT Bank

Dies ist ein systemseitiger Langwortmerker, der anzeigt, welche Bildbank der Fensternachschlagtabelle (WLUT) aktiv ist.
SGR$$K_SIDE_A - Fensterbildbank "A" ist derzeit aktiv.
SGR$$K_SIDE_B - Fensterbildbank "B" ist derzeit aktiv.
Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Perform_Traversal.

Dieser Langwortmerker wird von der SCS intern verwendet, um das Fehlen von Durchquerungsanforderungen am Ende der Anforderungsverarbeitung zu erfassen. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Swap_Bank_Request

Dieser Langwortmerker wird von der SCS intern verwendet, um sich zu merken, daß die Rahmenpufferbank am Ende der Durchquerungsverarbeitung ausgelagert werden muß. Es wird von den 3DDCs der doppeltgepufferten Rahmenbankfenster gesetzt. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Swap WLUT Request

Dieser Langwortmerker wird von der SCS intern verwendet, um sich zu merken, daß die Fensterbildbank der WLUT am Ende der Durchquerungsverarbeitung ausgelagert werden muß. Es wird von den 3DDCs der doppeltgepufferten WLUT-Bank-Fenster gesetzt. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Server_Rundown

Der Fensterserver 101 kann diesen Merker auf einen Wert ungleich 0 setzen, um die Strukturabarbeitungsvorrichtung 27 zu veranlassen, die Durchquerung der SCS geregelt zu beenden (am Ende der Durchquerungsphasenverarbeitung). Die Strukturabarbeitungsvorrichtung 27 wird ihn in ihrer letzten Aktion löschen, bevor sie die SCS-Durchquerung anhält.

o SCS.Num_Passes

Dieses Langwort enthält einen Zähler für die Durchläufe durch die SCS-Hauptschleife. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Num_Frames

Dieses Langwort enthält einen Zähler für die Anzahl der Ausführungen der SCS-Durchquerungsverarbeitung. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Previous Time

Zu Beginn jeder Anforderungs/Durchquerungs-Schleife der SCS wird dieses Langwort mit einem vom Steuerprozessor 13 gehaltenen 60-Hz-Systemzeitwert geladen. Es wird verwendet, um die SCS.Elapsed_Time zu bestimmen.

o SCS.Elapsed_Time

Dieses Langwort wird verwendet, um das Intervall der 60-Hz-Systemzeit zu halten, die zwischen den Anforderungs/Durchquerungs-Schleifen der SCS verstreicht. Dieser Wert wird in Blink- und wiederholten Durchquerungseinteilungsalgorithtmen verwendet.

o SCS.Watchdog_Timer

Die SCS wird dieses Langwort zu bestimmten Zeitpunkten während ihrer Ausführung mit einem maximalen Verarbeitungsintervall laden. Die Durchquerungssteuerfunktion innerhalb des Servers 100 wird diesen Zeitgeber periodisch dekrementieren und eine Zeitüberschreitungsverarbeitung ausführen, wenn der Zeitgeber erreicht.

o SCS.Event_Pointer

Dieses Langwort enthält die virtuelle Adresse eines Blocks von Daten, die einem Ereignis zugeordnet sind. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Queue_Node

Dieses Langwort enthält die Kennziffer eines Warteschlangenknotens innerhalb der SCS_Update_Processing- Unterstruktur.

o SCS.Pick_Id_Stack

Dieses Langwort enthält die Kennziffer eines Systemvorgabe-Pick-ID-Stapel-Knotens.

o SCS.Pic_Path_Stack

Dieses Langwort enthält die Kennziffer eines Systemvorgabe-Pick-Pfad-Stapel-Knotens.

o SCS.Call_Update_Node

Dieses Langwort enthält die virtuelle Adresse des Aufrufknotens in der SCS-Aktualisierungsverarbeitung. Dieser Knoten wird vom Aktualisierungsmechanismus benötigt, um die zurückgestellten Aktualisierungen an der SCS auszuführen. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Num_GCs

Dieses Langwort reflektiert die Anzahl der 3DGDCS in der an die SCS angefügten 3DGC-Liste. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.GC List Head

o SCS.GC_List_Tail

Diese Langwörter beschreiben die doppelt verkettete Liste der an die SCS angefügten 3DGCs. Sie sind Zeiger, die die Strukturspeicheradressen der 3DGC-Datenblöcke enthalten, oder sie sind beide "null", was das Fehlen von 3DGCs anzeigt. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf diese Langwörter.

o SCS.DC_List_Head

o SCS.DC_List_Tail

Diese Langwörter beschreiben die doppelt verkettete Liste der an die SCS angefügten 3DDCs. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf diese Langwörter.

o SCS.Current_GC_Pointer

Dieses Langwort wird mit der Strukturspeicheradresse des 3DGC-Datenblocks geladen, der derzeit von der SCS-Durchquerungsverarbeitung verarbeitet wird. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Current_DC_Pointer

Dieses Langwort wird mit der Strukturspeicheradresse des 3DDC-Datenblocks geladen, der an den derzeit von der SCS-Durchquerungsverarbeitung verarbeiteten 3DGC angefügt ist. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Current_Client_Pointer

Dieses Langwort wird mit der Strukturspeicheradresse des Stamms der Graphikdatenstruktur des Requesters 100 geladen, die an den derzeit von der SCS-Durchquerungsverarbeitung verarbeiteten 3DGC angefügt ist. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Current_GC_ID

Dieses Langwort wird mit der Graphikkontextidentifikation "GC ID" des von der SCS-Durchquerungsverarbeitung verarbeiteten 3DGC geladen. Die Requesterprozesse 100 können dieses Langwort prüfen, um festzustellen, welcher der wahrscheinlich mehreren 3DGCs eine Durchquerung angefordert hat.

o SCS.Current_GC_Start_Time

o SCS.Current_GC_End_Time

Diese Langwörter werden mit der vom Steuerprozessor 13 gehaltenen Systemzeit geladen, zu der die Durchquerung des 3DGC eingeleitet bzw. abgeschlossen wird. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o SCS.Current_Traversal_Type

Die Inhalte dieses Langworts reflektieren den Typ der derzeit ausgeführten Durchquerung. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.
- SGR$$K_DRAW_TRAVERSAL
- SGR$$K_HITTEST_TRAVERSAL

SCS-ORGANISATION

Im folgenden wird die Organisation der SCS-Struktur erläutert.
Die SCS-Struktur wechselt zwischen Anforderungs- und Durchquerungsverarbeitungsmodi. Während des Anforderungsmodus wird jeder 3DGC auf der an der SCS angefügten 3DGC- Liste der Reihe nach gesichtet. Wenn Anforderungen für Durchquerungen ausstehen und der aktuelle Zustand des 3DGC es erlaubt, werden die Merker im 3DGC-Datenblock aktualisiert, um die geeigneten Durchquerungen in der Durchquerungsverarbeitung zu veranlassen. Außerdem werden für all jene 3DGCs Zeichnungsdurchquerungen durchgeführt, die entweder die Rahmenpufferbank oder die Fenster-Nachschlagtabellen-Bildbank betreffen, wenn wenigstens eine Zeichnungsdurchquerungsanforderung an den 3DGC dieser besonderen Klasse gestellt worden ist.
Wenn wenigstens eine gültige Durchquerungsanforderung bei der Anforderungsverarbeitung erfaßt wurde, fährt der Durchquerungsverarbeitungsmodus fort, um alle angenommenen Anforderungen zu befriedigen. Dies wird bewerkstelligt, indem der Reihe nach jeder 3DGC auf der 3DGC-Liste gesichtet wird, und bei Bedarf Treffertest- und Zeichnungsdurchquerungen (in dieser Reihenfolge) durchgeführt werden. Jede Gruppierung der zwei Typen von Durchquerungen kann für einen 3DGC in jeweils einem vorgegebenen Durchquerungsdurchlauf ausgeführt werden, unter der Voraussetzung, daß die zugehörigen Anforderungen ausgegeben worden sind. Wenn keine Durchquerungsanforderungen aus stehen, bleibt die SCS bis zum nächsten Vertikairücklauf angehalten, bei dem die Anforderungsverarbeitung erneut ausgeführt wird. Dies wird durchgeführt, um eine unnötige Belastung des Strukturspeichers 26 zu vermeiden.
Wenn die SCS-Durchquerung eingeleitet wird, definiert die SCS sofort die Status- und Matrix-Stapelüberlauf-Bereiche, initialisiert einige interne Merker und tritt in ihre Hauptverarbeitungsschleife ein.

SCS_Update_Processing

Der erste Abschnitt der SCS-Schleife ist die SCS-Aktualisierungsverarbeitung. Dieser Abschnitt führt die zurückgestellten Aktualisierungen an der SCS unter Verwendung des Aktualisierungsmechanismus aus.

ANFORDERUNGSVERARBEITUNG

Der Anforderungsverarbeitungsabschnitt oder -modus der SCS-Schleife führt zwei Funktionen aus. Die erste Funktion ist, Modifizierungen an den 3DDC-Datenblocks vorzunehmen. Um dies durchzuführen, untersucht die Anforderungsverarbeitung alle 3DDCs, die dem System bekannt sind, und kippt die "aktive Hälfte" derjenigen, die anhängende Anforderungen ausgelagert haben. Diese Verarbeitung wird durchgeführt, um hier während der Anforderungsund Durchquerungsverarbeitung konsistente 3DDC-Daten sicherzustellen.
Zum zweiten sammelt die Anforderungsverarbeitung Durchquerungsanforderungen von den 3-D-Requestern 100 und dem Anzeigeverwalter (von den in den 3DDC-Datenblöcken enthaltenen Informationen). Diese Verarbeitung wird durchgeführt, indem die in der 3DGC-Liste enthaltenen 3DGC- Strukturen durchquert werden. Jeder 3DGC wird, nachdem sie den "Anforderungsphasen"-SCS-zustand erfaßt hat, alle an sie gerichteten, ausstehenden Durchquerungsanforderungen beantworten. Die Ergebnisse dieser Anforderungsverar beitung werden innerhalb des 3DGC zurückgehalten.
Wenn doppeitgepufferte 3DGCs gesichtet werden (jene mit 3DDCs, die sich entweder auf die Rahmenpufferbank oder auf die Fenster-Nachschlagtabellen-Bildbank beziehen), so wird außerdem eine Anforderung zum Auslagern dieser bestimmten Bank aufgezeichnet. Dies wird verwendet, um eine Zeichnungsdurchquerung aller solcher 3DGCs zu erzwingen, und veranlaßt eine Auslieferung der aktuellen Auslagerungsanweisungen am Ende der Durchquerungsverarbeitung.
Wenn nach der Sichtung jedes 3DGC keine Durchquerungsanforderungen erfaßt werden, versetzt sich die SCS selbst in einen Wartezustand. Der Steuerprozessor 13 (ACP) wird die SCS-Durchquerung beim nächsten Vertikairücklauffortsetzen.
Der Durchquerungsverarbeitungsabschnitt oder -modus der SCS-Schleife sichtet jeden in der 3DGC-Liste beschriebenen 3DGC. Diese Aktion leitet in Abhängigkeit von Ergebnissen der Anforderungsverarbeitung und der in jedem 3DGC enthaltenen Modusinformationen Durchquerungen ein. Bestimmte hardwarespezifische Operationen schließen die aktuellen Kontextdurchquerungen ein. Außerdem können einer oder beide Bankmerker als Folge der in der vorangehenden Anforderungsverarbeitung durchgeführten Fenstertyperfassung gekippt werden.

GRAPHIKKONTEXTE

Eine 3D-Graphikkontext-(3DGC)-Steuerstruktur enthält die Graphikattribute und Steuerinformationen, die erforderlich sind, um alle Typen von Durchquerungen einer Graphikdatenstruktur eines Requesters 100 anzufordern und auszuführen.
Obwohl "3DGC" als eine einzigartige Instanz der 3DGC- Struktur bezeichnet wird, enthält die Durchquerungssteuerung jedoch eine einzelne Instanz der aktuellen Steuerungsstruktur, bekannt als der "generische" 3DGC. Diese Struktur besitzt einen Zeiger auf einen "3DGC-Datenblock", der die Informationen zur Verfügung stellt, die einer bestimmten 3DGC-Instanz entsprechen. Diese 3DGC-Datenblöcke sind in der 3DGC-Liste enthalten.

3DGC-ERZEUGUNG UND STEUERUNG

Ein 3DGC wird vom Server 101 immer dann erzeugt, wenn ein Requester 100 SGR$CREATE_CONTEXT aufruft. Wenn der 3DGC zugewiesen und erzeugt ist, plaziert ihn der Server 101 am Ende der 3DGC-Liste. Wenn der Server 101 erfaßt, daß ein Requester 100 zum Ende gekommen ist, werden alle 3DGCs, die diesem Requester gehören, deaktiviert. Die zugehörigen 3DGC-Datenblöcke werden nicht getrennt und wiederverwendet, bis die Anforderungsverarbeitung die Deaktivierungsanforderung bestätigt hat.
Der Requester 100 kann einen 3DDC zu einem 3DGC hinzubinden, indem er folgenden SGR-Aufruf ausführt:

SGR$SET_DEF_DRAWABLE gc, window_id, flag

Ein Requester kann eine Graphikdatenstruktur eines Requesters 100 zu einem 3DGC hinzubinden, indem er folgenden SGR-Aufruf ausführt:

SGR$SET DEF VIRTUAL ROOT gc, handle

3DGC- DATENBLOCK

Die generische 3DGC-Struktur besitzt einen Zeiger auf den "3DGC-Datenblock" entsprechend dem durchquerten 3DGC. Dieser Datenblock enthält Steuerinformationen, die für den 3DGC spezifisch sind und wie folgt definiert sind:

o 3DGC.Flink

o 3DGC.Blink

Diese Langworte enthalten Strukturspeicheradressen, die als Verbindungen in doppelt verketteten 3DGC-Listen dienen. Die Durchquerungssteuerfunktion im Server 101 benötigt einen exklusiven Schreibzugriff auf diese Langwörter.

o 3DGC.System Enabled

Dieser Langwortmerker wird von der SCS gesetzt, wenn der 3DGC zur 3DGC-Liste hinzugefügt wird. Er wird vom Server 101 gelöscht, wenn (1) ein Durchquerungszeitüberlauf auftritt, während dieser 3DGC durchquert wird, oder (2) von der SCS eine Deaktivierungsanforderung erfaßt wird. Wenn dieser Merker gesetzt ist, wird der 3DGC effektiv aus dem System entfernt.

o 3DGC.Kill

Dieser Langwortmerker wird von der Durchquerungssteuerfunktion im Server 101 gesetzt, wenn der besitzende Requester 100 abstürzt. Er ist quasi eine Deaktivierungsanforderung und wird als Bestätigung, daß der 3DGC nicht länger aktiv ist, von der SCS gelöscht.

o 3DGC.Dead

Dieser Langwortmerker wird von der SCS gesetzt, wenn eine kill-Anforderung erfaßt wird. Er wird verwendet, um jene 3DGC-Datenblöcke in der 3DGC-Liste zu identifizieren, die unverkettet sein können und von der Durchquerungssteuerfunktion im Server 101 wiederverwendet werden können.

3DGC.System_Flags

Dieses Langwort enthält Bitmerker, die von der SCS verwendet werden. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.
- Do_DC_Draw
- Do_Client_Draw
- Do_Hit_Test
- Diese Merker dienen zum Aufzeichnen der von der SCS-Anforderungsverarbeitung akzeptierten Durchquerungsanforderungen.
- Bank_2B
- WLUT_2B
- Diese Merker werden von der Anforderungsverarbeitung gesetzt/gelöscht, um den Typ der Doppelpufferung aufzuzeichnen, der von dem angegebenen 3DDC (falls vorhanden) angegeben wird. Die Durchquerungsverarbeitung verwendet diese Merker, um festzustellen, ob für diesen 3DGC selbst bei Fehlen einer expliziten Anforderung eine Zeichnungsdurchquerung ausgeführt werden muß.

o 3DGC.Num_Request_Passes

o 3DGC.Num_Traversal_Passes

Diese Langwörter geben wieder, wie oft dieser spezielle 3DGC durchquert worden ist und warum. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf diese Langwörter.

o 3DGC.Num_Timeouts

Dieses Langwort enthält einen Zähler für die Häufigkeit des Auftretens einer Zeitüberschreitung während der Durchquerung dieses 3DGC.

o 3DGC.Num_Update

Dieses Langwort enthält einen Zähler für die Häufigkeit eines Auffrischungs-Warteschlangenknotens innerhalb dieser Durchquerung des 3DGC.

o 3DGC.Blink_On_Timer

Dieses Langwort wird verwendet, um festzustellen, wann eine "blink-on"-Durchquerung auszuführen ist.

o 3DGC.Blink_Off_Timer

Dieses Langwort wird verwendet um festzustellen, wann eine "blink-off"-Durchquerung auszuführen ist.

o 3DGC.Repeat_Timer

Dieses Langwort wird verwendet, um festzustellen, wann eine "wiederholte" Durchquerung auszuführen ist.

o 3DGC.TCID

Dieses Langwort enthält die X-Window-System-Betriebsmittelnummer des diesem 3DGC zugeordneten Durchquerungskontextes.

o 3DGC.Traversal_Type

Dieses Langwort enthält eine Kopie von SCS.Current_Traversal_Type, der der Requester-Struktur zur Verfügung gestellt wird, um eine durchquerungstypspezifische Verarbeitung zu erlauben.

o 3DGC.Num_Draw_Traversals

o 3DGC.Num_Hit_Test_Traversals

Dieses Langwörter enthalten Zähler für die Anzahl der Durchquerungen. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf diese Langwörter.

o 3DGC.Blink_State

Dieses Langwort enthält den aktuellen Blinkzustand:
- SGR$K_BLINK_ON
- SGR$K_BLINK_0FF

o 3DGC.Blink_Mask

Dieses Langwort enthält eine Kopie von SCS.Blink_Mask, das der Requester-Struktur für apenodische Blinkoperationen zur Verfügung gestellt wird.

o 3DGC.VR_Count

Dieses Langwort enthält eine Kopie der 60-Hz-Systemzeit.

o 3DGC.GC ID

Dieses Langwort enthält einen 3DGC-Identifizierer, der vom Server 101 zugewiesen wird und bei Bedarf vom Requester 100 modifiziert werden kann. Die SCS verwendet die Adresse des 3DGC-Datenblocks, um 3DGCs zu löschen, so daß diese ID nicht einzigartig sein muß.

o 3DGC.DC_Data_Pointer

Dieses Langwort enthält die Strukturspeicheradresse des an diesen 3DGC angefügten 3DDC-Datenblocks oder 0, falls keiner angefügt ist. Die Durchquerungssteuerfunktion im Fensterserver 101 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o 3DGC.Client_Root

Dieses Langwort enthält die Strukturspeicheradresse der an diesen 3DGC angefügten Requester-Anzeigestruktur oder 0, falls keine angefügt ist. Der Requesterprozeß 100, der den 3DGC besitzt, benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o 3DGC.Call_Update_Node

Dieses Langwort enthält die virtuelle Adresse eines Aufrufknotens, der vor jeder Zeichnungsdurchquerung durchquert wird. Dieser Knoten wird vom Aktualisierungsmechanismus benötigt, um zurückgesteilte Aktualisierungen an der angefügten Requesterstruktur durchzuführen. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o 3DGC.Client_Flags

Dieses Langwort enthält Durchquerungsmodus-Bits, die vom Requester 100 durch folgenden SGR-Aufruf gesteuert werden:

SGR$SET_DEF_TRAVERSAL_MODE gc, modeflags

Automatic - Falls gesetzt, kann, wenn der angefügte 3DDC ein "doppeltgepuffertes" Fenster ist, die SCS diesen 3DDC immer erneut durchqueren, wenn die Systemanzeigepuffer ausgelagert werden.
Redisplay - Falls gesetzt, kann der Anzeigeverwalter im Server 101 bei Bedarf Zeichnungsdurchquerungen dieses 3DGC anfordern, um auf der Anzeigevorrichtung ein korrektes Bild zu halten.
Repeated - Falls gesetzt, werden Zeichnungsdurchquerungen dieses 3DGC mit einer periodischen Häufigkeit durchgeführt, die durch 3DGC.Repeat_Period bestimmt ist.
Blink - Falls gesetzt, werden Zeichnungsdurchquerungen dieses 3DGC mit einer dual-periodischen Häufigkeit durchgeführt, die durch 3DGC.Blink_On_Period und 3DGC.Blink_Off_Period bestimmt ist.

o 3DGC.Blink On Period

o 3DGC.Blink_Of_Period

o 3DGC.Repeat_Period

Diese Langwörter enthalten Zeitintervalle, die die Periodizität von Zeichnungsdurchquerungen bestimmen, wenn der Wiederholungs- oder Blinkdurchquerungsmodus wirksam ist.

o Client_Draw_Request

Dieser Langwortmerker wird vom Requester auf einen Wert ungleich 0 gesetzt, um mit dem folgenden SGR- Aufruf eine Zeichnungsdurchquerung anzufordern:

traversal_type = SGR$K_DRAW_TRAVERSAL SGR$REQUEST_TRAVERSAL display, gc, traversal_type

Die SCS wird den Merker löschen, nachdem die Anforderung erfaßt ist.

o Client_Draw_Pending

Dieser Langwortmerker wird von der SCS auf einen Wert ungleich 0 gesetzt, um anzuzeigen, daß eine Requester-Zeichnungsanforderung entdeckt worden ist. Die SCS wird den Merker löschen, wenn die Durchquerung abgeschlossen ist.

o Notify on Draw

Dieser Langwortmerker wird vom Fensterserver 101 auf einen Wert ungleich 0 gesetzt, wenn der Requester 100 eine Benachrichtigung über den Zeichnungsdurchquerungsabschluß anfordert. Die SCS wird den Merker löschen, nachdem die Durchquerung abgeschlossen ist, unmittelbar bevor das Ereignis an den Steuerprozessor 13 weitergeleitet wird.

o Draw_Sequence_Number

Die Inhalte dieses Langworts sind im Benachrichtigungsereignis enthalten, das als Ergebnis einer abgeschlossenen Zeichnungsdurchquerung geliefert wird. Die Durchquerungssteuerfunktion im Server 101 benötigt einen exklusiven Schreibzugriff auf dieses Langwort.

o Client_Hittest_Request

o Client_Hittest_Pending

o Notify_on_Hittest

o Hittest_Sequence_Number

Diese Langwörter werden für Hittest-Durchquerungen in einer Weise ähnlich den obenerwähnten Zeichnungsdurchquerungsvariablen verwendet.

o Sync_Request

o Sync_Pending

o Notify_on_Sync

o Sync_Sequence Number

Diese Langwörter werden vom Server 101 verwendet, um sich mit der SCS zu synchronisieren.

3DGC-ORGANISATION

Der 3DGC wird in Abhängigkeit vom Inhalt der SCS-Zustandsvariablen in eine Anforderungsverarbeitung und eine Durchquerungsverarbeitung aufgeteilt
Die Anforderungsverarbeitung erfordert, daß der 3DGC sowohl vom System als auch vom Requester 100 freigegeben wird, bevor irgendeine Durchquerungsanforderungsverarbeitung ausgeführt wird. Wenn diese Bedingung zutrifft, werden Anforderungen für Service-Durchquerungen akzeptiert. Wenn ein "sichtbarer" 3DDC zu einem 3DGC hinzugebunden wurde, werden Zeichnungsdurchquerungsanforderungen akzeptiert. Wenn der Requester 100 diesen 3DGC gesperrt hat und eine Bestätigung angefordert hat, wird der Requester 100 benachrichtigt.
Die Deaktivierungsverarbeitung wird ungeachtet des SCS- Zustands ausgeführt. Wenn der 3DGC vom System freigegeben ist und eine "kill"-Anforderung anhängig ist, wird der 3DGC als "dead" markiert und vom System gesperrt. Obwohl der 3DGC-Datenblock immer noch mit der 3DGC-Liste verkettet ist, ist er dann für die Abtrennung und Wiederverwendung verfügbar.

ANZEIGEKONTEXTE

Eine 3D-Anzeigekontext-(3DDC)-Steuerstruktur bestimmt die Abbildung der vom Requester erzeugten Bilder auf einer rechtwinkligen Fläche des Bildschirms. Wenn der 3DDC vom 3DGC aufgerufen wird, lädt er den Untersystemzustand, der sich auf das zugehörige Anzeigeverwalterfenster (die Wiedergabeumgebung) bezieht. Der 3DDC erhält einen Hinweis auf die derzeit angezeigte Bank. Dieser wird verwendet, um bankabhängige Attribute wie z. B. Schreibmasken usw. zu setzen.
Die Wiedergabeumgebung umfaßt:
o Fensteranzahl
o Fenstermaske
o Vordergrundfarbe
o Hintergrundfarbe
o Basismatrix
o Basisarbeitsbereich
o Pixelformat
o Vorgabe-Linienfilter
o Pixelprozessoreinstellung
o Filterrundung-Freigabe/Sperrung
o Verwenden gültiger Ebenen beim FB-Lesen
o Rahmenpufferschreibmaske
o Pipeline-Freigabemaske
Obwohl ein "3DDC" als eine einzigartige Instanz der 3DDC- Struktur bezeichnet wird, hält die Durchquerungssteuerung jedoch eine einzelne Instanz der aktuellen Steuerstruktur, bekannt als der "generische" 3DDC. Dieser Struktur wird ein Zeiger auf einen "3DDC-Datenblock" übergeben, der die einer bestimmten 3DDC-Instanz entsprechenden Informationen zur Verfügung stellt.

3DDC-ERZEUGUNG UND STEUERUNG

Ein Requester-Prozeß 100 erzeugt ein Fenster, indem eü an das Fenstersystem 101, 102, 103 einen geeigneten Aufruf richtet. Als Ergebnis dieser Aktion gibt der Anzeigeverwalter eine Beschreibung des Fensters (in einem "3DDC- Deskriptor") an die Durchquerungssteuerfunktion im Server 101 weiter. Diese Routine belegt einen 3DDC-Datenblock und formatiert ihn mit den aus dem 3DDC-Deskriptor extrahierten Informationen. Wenn der Requestor 100 dieses Fenster an einen 3DGC anfügen will (oder später davon trennen will), wird er den folgenden SGR-Aufruf ausführen. Diese Routine wird in Abhängigkeit vom Merkerparameter die Adresse des 3DDC-Datenblocks entweder in den entsprechenden 3DGC-Datenblock eintragen oder aus diesem entfernen.

SGR$$SET_DEF_DRAWABLE gc, window_id, flag

Der Anzeigeverwalter kann den 3DDC-Datenblock als Antwort auf Veränderungen der Fensterattribute modifizieren. Eine Zeichnungsdurchquerungsanforderung wird für alle 3DGCs ausgegeben, die an diesen 3DDC angefügt sind, falls der 3DDC nach der Modifikation sichtbar bleibt.

3DDC-DATENBLOCK

o 3DDC-Flink

o 3DDC.Blink

Diese Langwörter enthalten Strukturspeicheradressen, die in der doppelt verketteten 3DDC-Liste als Verbindungen dienen. Die Strukturabarbeitungsvorrichtung 27 benötigt einen exklusiven Schreibzugriff auf diese Langwörter.

o 3DDC.System_Enabled

Dieser Langwortmerker wird von der SCS gesetzt, wenn der 3DDC an die 3DDC-Liste angefügt wird. Er wird infolge einer Deaktivierungsanforderung von der SCS gelöscht.

o 3DDC.Kill

Dieser Langwortmerker wird von der Durchquerungssteuerfunktion im Server 101 gesetzt, wenn der besitzende Requester 100 abstürzt. Er ist quasi eine Deaktivierungsanforderung und wird als Bestätigung, daß der 3DDC nicht mehr aktiv ist, von der SCS-Anforderungsverarbeitung gelöscht.

o 3DDC.Dead

Dieser Langwortmerker wird von der SCS gesetzt, wenn eine kill-Anforderung erfaßt wird. Er wird verwendet, um jene 3DDC-Datenblöcke in der 3DDC-Liste zu identifizieren, die getrennt und von der Durchquerungssteuerfunktion im Server 101 wiederverwendet werden können.

o 3DDC.Swap_Request

Dieses Langwort wird verwendet, um den Zugriff der Strukturabarbeitungsvorrichtung 27 und des Servers 101 auf den 3DDC-Datenblock zu synchronisieren. Wenn die Durchquerungssteuerfunktion im Server 101 diesen Merker gelöscht vorfindet, kann sie sofort auf die "inaktive" Hälfte des 3DDC-Datenblocks zugreifen. Zu diesem Zeitpunkt kann sie die inaktive Hälfte aktualisieren und dieses Langwort auf einen Wert ungleich 0 setzen. Wenn die SCS diesen Merker gesetzt vorfindet, wird sie die aktiven und inaktiven Hälften vertauschen und diesen Merker löschen.
Wenn die Durchquerungssteuerfunktion im Server 101 diesen Merker gesetzt vorfindet (was anzeigt, daß die SCS noch eine vorangehende Auslagerungsanforderung bearbeiten muß), hat sie zwei Möglichkeiten;
(a) Sie kann warten, bis die SCS diesen Merker löscht. Dies stellt sicher, daß die vorangehend aktualisierte Hälfte wenigstens einmal gesichtet worden ist.
(b) Sie kann den Merker selbst löschen, eine kurze Zeitspanne warten und anschließend die "inaktive" Hälfte zu diesem Zeitpunkt aktualisieren. Es ist jedoch zu beachten, daß die vorangehende Auslagerungsanforderung sehr wahrscheinlich ignoriert wird. Das Warten ist für den Fall erforderlich, daß die SCS die vorherige Anforderung gerade verarbeitet. (Achtungsunterbrechungen werden von der SCS während dieser Zeitspanne (für drei Knoten) gesperrt, so daß dieser kritische Bereich gut eingeschränkt ist).

o 3DDC.Active_Half

Dieses Langwort zeigt an, welche der "Hälften" dieses 3DDC-Datenblocks derzeit von der SCS-Anforderung und der Durchquerungsverarbeitung verwendet wird. Wenn es gleich 0 ist, ist die erste Hälfte aktiv, ansonsten ist die zweite Hälfte aktiv.
Der 3DDC-Datenblock enthält aufeinanderfolgende Kopien (Hälften) der folgenden Gruppe von Einträgen.

o 3DDC.Visible

Wenn dieser Langwortmerker ungleich 0 ist, ist das bezeichnete Fenster (zumindest teilweise) auf dem Bildschirm sichtbar. Wenn er gleich 0 ist, ist das Fenster entweder vollständig verdeckt oder als Symbol dargestellt, wobei in diesem Fall keine Zeichnungsdurchquerungen versucht werden.

o 3DDC.Draw_Request

Dieser Langwortmerker wird auf Geheiß des Datenverwalters auf einen Wert ungleich 0 gesetzt, um für alle 3DGCs, die mit diesem 3DDC verbunden sind, Zeichnungsdurchquerungen anzufordern. Diese Aktion kann z. B. erforderlich sein, wenn ein Fenster von einem Freilegungsereignis oder einer Größenänderungsoperation betroffen ist. Die SCS wird diesen Merker nach der ersten Zeichnungsdurchquerung eines mit diesem 3DCC verbundenen 3DGC löschen.

o 3DDC.Window_Number

Dieses Langwort enthält die Fensternummer in einem Format, das zum Eintragen in einen generischen Knoten geeignet ist.

o 3DDC.Window_Mask

Dieses Langwort enthält die Fenstermaske in einem Format, das zum Eintragen in einen generischen Knoten geeignet ist.

o 3DDC.Pixel Format

Dieses Langwort enthält das Pixelformat dieses Fensters.
- 1B, 4 Bit abgebildet
- 1B, 4 Bit Grauskala
- 1B, 8 Bit abgebildet
- 1B, 8 Bit Grauskala
- 1B, 12 Bit RGB
- 1B, 24 Bit RGB
- WLUT 28, 4 Bit abgebildet
- WLUT 28, 4 Bit Grauskala
- WLUT 28, 8 Bit abgebildet
- WLUT 28, 8 Bit Grauskala
- WLUT 28, 12 Bit RGB
- Bank 28, 4 Bit abgebildet
- Bank 28, 4 Bit Grauskala
- Bank 28, 8 Bit abgebildet
- Bank 28, 8 Bit Grauskala
- Bank 28, 12 Bit RGB
- Bank 28, 24 Bit RGB

o 3DDC.Background_Color

Dieses Langwort enthält die Fensterhintergrundfarbe in einem Format, das für einen Eintrag in einen Set- Background-Knoten geeignet ist.

o 3DDC.Foreground_Color

Dieses Langwort enthält die virtuelle Adresse des Basismatrix-X3-Knotens, der zum Laden der Basismatrix durchquert wird.

o 3DDC.Base_Matrix_SGR

o 3DDC.Base_Matrix_GDS

Dieses Langwort enthält die physikalische Adresse des Basismatrix-Graphikanzeigestruktur-Knotens, der zum Laden der Basismatrix durchquert wird.

o 3DDC.Base_Viewport_SGR

Dieses Langwort enthält die virtuelle Adresse des Basisarbeitsbereichs-X3-Knotens, der zum Laden des Basisarbeitsbereichs durchquert wird.

o 3DDC.Base_Viewport_GDS

Dieses Langwort enthält die physikalische Adresse des Basisarbeitsbereichs-Graphikdatenstruktur-Knotens, der zum Laden des Basisarbeitsbereichs durchquert wird. 3DDC-ORGANISATION
Es folgt eine Zusammenfassung der verschiedenen Routinen, die in den Requestern 100 und im Server 101 abgelegt sind, um diesen zu ermöglichen, mit den Durchquerungssteuerungsstrukturen zu kommunizieren.

SGR$CREATE_CONTEXT display, gc

display

Dies ist die X-Window-System-Anzeigevariable, die eine bestimmte Verbindung zu einem Server 101 spezifiziert.

gc

Dies ist der Identifizierer des erzeugten 3DGC.
Ein Requesterprozeß 100 ruft diese Röutine auf, um einen Graphikkontext (3DGC) zu erzeugen.

SGR$SET_DEF_DRAWABLE gc, window_id, flag

gc

Dies ist die "3DGC-ID" des angefügten 3DGC.

window_id

Dieses Langwort enthält eine Identifizierung des Fensters, das am 3DGC angefügt oder von diesem entfernt werden soll.

flag

Wenn dieses Langwort ungleich 0 ist, wird das Fenster angefügt. Wenn es gleich 0 ist, wird das Fenster entfernt.
Ein Requester-Prozeß 100 ruft diese Routine auf, um ein Fenster (3DDC) an einen Graphikkontext (3DGC) anzufügen oder von diesem zu entfernen.

SGR$SET_DEF_VIRTUAL_ROOT gc, handle

gc

Dies ist die "3DGC-ID" des zu ergänzenden 3DGC.

handle

Dieses Langwort enthält die virtuelle Adresse des Knotens, in den als Stammknoten des 3DGC der Requesterstruktur eingestiegen werden soll.
Ein Requester-Prozeß 100 ruft diese Routine auf, um eine Graphikdatenstruktur (Requester-Struktur) an einen Graphikkontext (3DGC) anzufügen.

SGR$SET_DEF_TRAVERSAL_MODE gc, modeflags

gc

Dies ist die "3DGC-ID" des 3DGC zum Empfangen neuer Durchquerungsmodi.

modeflags

Dieses Langwort spezifiziert die Durchquerungsmodi, wie sie mit Bezug auf 3DGC.Client_Flags auf Seite 69 beschrieben worden sind.
Ein Requester-Prozeß 100 ruft diese Routine auf, um die geeigneten Durchquerungsmodi des 3DGC einzustellen. Diese Modi beeinflussen nachfolgende Durchquerungen des 3DGC.

SGR$REQUEST_TRAVERSAL gc, traversal_type

gc

Dies ist der zu durchquerende 3DGC.

traversal_type

Dies spezifiziert den Typ der gewünschten Durchquerung:
* SGR$K_DRAW_TRAVERSAL - für eine Zeichnungsdurchquerung.
* SGR$K_HITTEST_TRAVERSAL - für eine Treffertestdurchquerung
Ein Requester-Prozeß 100 ruft diese Routine auf, um anzufordern, daß ein bestimmter Typ einer Durchquerung für den 3DGC ausgeführt wird.

SGR$INQ_TRAVERSAL STATE gc, traversal_type, waitflag, state

Dies ist der in Frage kommende 3DGC.

traversal_type

Dieses Langwort wird verwendet, um den Typ der in Frage kommenden Durchquerung zu spezifizieren.
* SGR$K_DRAW_TRAVERSAL - für einen Zeichnungsdurchquerungsabschluß
* SGR$K_HITTEST_TRAVERSAL - für einen Treffertestdurchquerungsabschluß

waitflag

Wenn dieser Langwortmerker ungleich 0 ist, wird diese Routine nicht zurückkehren, bis das spezifizierte Ereignis eingetreten ist. Andernfalls wird unmittelbar der Status des Ereignisses zurückgegeben.
Ein Requester-Prozeß 100 ruft diese Routine auf, um den Status oder eine Mitteilung für einen bestimmten Durchquerungsabschluß zu erhalten.

SGR$STARTUP

Der Server 101 ruft diese Routine auf, um die Durchquerungssteuerfunktion zu initialisieren, die im Serverprozeß 101 operiert. Diese Aktion umfaßt das Erzeugen aller Steuerstrukturen und die Einleitung der SCS-Durchquerung.

SGR$CREATE_3DGC gc, 3dgc_db

gc

Dies ist der Identifizierer des zu erzeugenden 3DGC.

3dgc_db

Die virtuelle Adresse des 3DGC-Datenblocks, der dem neuen 3DGC zugeordnet ist, wird in diesem Langwort zurückgegeben.
Der Server 101 ruft diese Routine auf, um als Antwort auf einen Requester 100, der SGR$CREATE_CONTEXT aufruft, eine neue 3DGC-Struktur zu erzeugen.

SGR$CREATE_3DDC_descriptor, 3ddc_db

3ddc_descriptor

Eine Struktur von Langwörtern, die mittels Referenz weitergegeben wird und eine anfängliche Beschreibung des Fensters enthält.

3ddc_db

Die virtuelle Adresse des erzeugten 3DDC-Datenblocks, mittels Referenz zurückgegeben.
Der Server 101 ruft diese Routine auf, um die 3DDC-Struktur zu erzeugen, die einem neu definierten Fenster zugeordnet werden soll. Die Adresse des zurückgegebenen 3DDC- Datenblocks kann anschließend verwendet werden, um dieses Fenster mit einer beliebigen Anzahl von 3DGCs zu verbinden.

SGR$UPDATE_3DDC 3ddc_descriptor, 3ddc_db

3ddc_descriptor

Eine Struktur von Langwörtern, die mittels Referenz weitergeleitet werden und eine aktualisierte Beschreibung des Fensters enthalten.

3ddc_db

Die virtuelle Adresse des zu aktualisierenden 3DDC-Datenblocks, mittels Referenz weitergeleitet.
Der Server 101 ruft diese Routine auf, um die 3DDC-Struktur zu aktualisieren, die einem neu definierten/modifizierten Fenster zugeordnet ist. Diese Routine kann eine Zeichnungdurchquerung aller mit diesem Fenster verbundenen 3DGCs anfordern, unter der Voraussetzung, daß das Fenster sichtbar ist und die 3DGCs entsprechend freigegeben sind.

SGR$RUNDOWN

Der Server 101 ruft diese Routine auf, um die Durchquerung der SCS geregelt zu beenden.
Aus der obigen Beschreibung der Durchquerungssteuerfunktionen wird klar, daß die dreidimensionalen Graphikkontexte (3DGCs) alle Durchquerungssteuerfunktionen zusammenfassen. Die Durchquerung jedes 3DGC mittels der Strukturabarbeitungsvorrichtung 27 durch die Anforderungsverarbeitungs- und Durchquerungsverarbeitungsmodi der SCS stellt der Strukturabarbeitungsvorrichtung 27 Graphikattribute und Steuerungsinformationen zur Verfügung, die erforderlich sind, um alle Durchquerungen einer Graphikdatenstruktur auszuführen. Wie in Fig. 5 gezeigt, ist jeder Requester 100 mit Aufrufen und Routinen versehen, um eine Graphikdatenstruktur (GDS) über einen virtuellen 3D- Stamm an einen 3DGC anzufügen und die Durchquerungsanforderungsmerker im angefügten 3DGC zu steuern. Der Requester 100 kann ferner einen Aufruf tätigen, um einen 3DGC an den vom Anzeigeverwalter erzeugten 3DDC zu binden, um dem X-Window-System eine dreidimensionale Funktionalität zu verleihen. Auf diese Weise wird die asynchrone Durchquerung des Strukturspeichers 26 mittels des Durchquerungsanforderungsmechanismus, der den mehreren Requestern 100 zur Verfügung steht, und durch die Anforderungs- und Durchquerungsverarbeitungsmodi gesteuert, um systematisch eine Knotendurchquerungsreihenfolge für einen geordneten Fluß von Graphikdaten und Anweisungen über die Leitung 30 zum Graphik-Pipeline-Prozessor 29 zu erzeugen. Der geordnete Fluß von Graphikdaten und Anweisungen stellt eine maximale Effizienz bei der Verwendung der Betriebsmittel des Graphikuntersystems 17 sicher, um mehrere Anwendungsprogramme durch Organisieren der Durchquerungsanforderungen und der zugehörigen Graphikdatenstrukturen und Fensterinformationen über die 3DGCs und die verbundenen 3DDCs für die kontinuierliche asynchrone Durchquerungsoperation der Strukturabarbeitungsvorrichtung 27 effizient zu verarbeiten.

WIEDERGABEPROZESSORSTEUERUNG UND BITRASTERGRAPHIKSCHNITTSTELLE

Das Graphikuntersystem 17 der Erfindung schafft zwei Typen von Graphikumgebungen für den Benutzer: 3-D-Graphiken, wie obenbeschrieben, und Bitraster-(2-D)-Graphiken. Die Bitraster-Umgebung ist der 3-D-Umgebung ähnlich, obwohl sie etwas einfacher ist. Wie bei der 3-D-Anwendung kommuniziert eine Bitraster-Anwendung mit dem Graphikuntersystem 17, indem sie die im gemeinsam genutzten Speicher (Strukturspeicher 26) gespeicherten Datenstrukturen verwendet. Diese Datenstrukturen, die Bitraster-Graphikdatenstrukturen, werden vom Wiedergabeprozessor 36 durchquert und verarbeitet.
Der Wiedergabeprozessor 36 bewältigt im System mehrere Aufgaben: 3-D-Wiedergabe, Bitraster-Wiedergabe, Bitraster-Graphikdatenstruktur-Durchquerung und Videountersystem-Steuerung. Der Ausdruck "Wiedergabe" bezieht sich bei Computergraphiken auf Techniken wie z. B. Colorierung, Schattierung und Beleuchtung, die verwendet werden, um ein Objekt wirklichkeitsnah zu zeichnen. Der Wiedergabeprozessor 36 regelt ferner die Einteilung der Bitraster- und 3-D-Graphikoperationen. Zusätzlich zur Durchquerung und Wiedergabe erzeugt der Wiedergabeprozessor 36 eine Schnittstelle für das Videountersystem (Farben-Nachschlagtabelle, Fenster-Nachschlagtabelle und Cursorverwaltung).
Der Wiedergabeprozessor 36 ist ein gemeinsam genutztes Betriebsmittel im Kontext der Bitraster-Graphik. Die Graphik bietet zwei Schnittstellenebenen. Die erste Schnittstelle bietet einen primitiven Zugriff auf Hardware- /Mikrocode-Einrichtungen mit geringer Abstraktion. Die zweite Schnittstelle ist eine Modellebenenschnittstelle, die die Funktionalität und Semantik zur Verfügung stellt, die von Standard-Digitalfenstersystemen (X oder UIS) erwartet werden. Die Schnittstelle zwischen dem Wiedergabeprozessor 36 und dem Rest des Graphiksystems wurde so ausgelegt, daß sie die gemeinsame Nutzung des Wiedergabeprozessors 36 seitens der Bitraster-Graphik- und 3-D-Graphikanwendungen optimiert.

GRAPHIKKONTEXT

Der Wiedergabeprozessor 36 und die Zeichnungshardware halten einen Zustand, der verwendet oder modifiziert wird, wenn Graphikanweisungen ausgeführt werden. Die Gesamtheit aller solcher Zustände umfaßt einen Kontext, in welchem Zeichnungsanweisungen ausgeführt werden. Dieser Kontext, der Hardwarekontext, wird allein durch die Verwendung von Anweisungen verwaltet, die vom Wiedergabeprozessor 36 ausgeführt werden. Eine Multitasking-Graphikumgebung wird erhalten, indem dieser eine Hardwarekontext von mehreren Graphikkontexten gemeinsam genutzt wird. Ein Graphikkontext stellt einen Teilprozeß der Ausführung und den Zustand dar, der für die Ausführung der Anweisung in diesem Teilprozeß benötigt wird. Multitasking wird weitgehend auf die gleiche Weise durchgeführt, wie mehrere Prozeßkontexte einen Hardwarekontext in einem in einem Teilnehmersystem gemeinsam nutzen: Einteilung und Ausführung. Graphikkontexte werden vom Wiedergabeprozessor durchquert, wobei jene für die Ausführung eingeteilt werden, die markiert sind.
Zusätzlich zum Multitasking bietet jeder Graphikkontext einen Zustand und einen Mechanismus, um diesen Zustand dynamisch zu jedem beliebigen Zeitpunkt während der Ausführung der Graphikanweisungen in die Graphikhardware zu laden. Auf diese Weise wird der Teilprozeß der Ausführung von dem Zustand, der zur Ausführung erforderlich ist, abgekoppelt.
Die Ausführung eines Graphikkontextes findet in zwei Phasen statt: Ladephase und Aktualisierungsphase. Während der Ladephase wird der Hardwarekontext in einen Zustand versetzt, der mit dem geladenen Graphikkontext verträglich ist. Die Ladephase für einen Bitraster-Graphikkontext stellt typischerweise im Hardwarekontext einen Zeichnungszustand ein, führt jedoch selten eine Zeichnung aus. Die Ladephase für einen 3-D-Graphikkontext stellt typischerweise im Hardwarekontext einen Zustand ein, zeichnet jedoch auch ein Bild, das eine Ansicht einer Welt enthält.
Während der Aktualisierungsphase werden Anweisungen verarbeitet, die die Beschreibung einer Welt verändern. Die Beschreibung einer Bitraster-Welt ist in einer Bitraster- Datenstruktur enthalten, so daß eine Aktualisierung der Beschreibung ein Bearbeiten eines Bitrasters (Rasterung) erfordert.
Die Beschreibung einer 3-D-Welt ist in einer komplexeren Datenstruktur enthalten. Diese Datenstruktur wird üblicherweise während der Ladephase durchquert, so daß eine Aktualisierung der Beschreibung eine Bearbeitung eines Teils der Datenstruktur erfordert. Sowohl im 3-D-Fall als auch im Bitraster-Fall wird eine Datenstruktur bearbeitet, wobei der einzige Unterschied in den verwendeten Datentypen und Operationen besteht.
Der Wiedergabeprozessor 36 lädt einen Bitraster-Graphikkontext, indem er eine Liste von Anweisungen ausführt, die den Hardwarekontext aktualisieren; diese Liste wird als die Initialisierungsliste bezeichnet. Die Intitialisierungsliste wird verwendet, um eine Verträglichkeit des Hardwarekontextes zu erreichen, bevor irgendwelche Zeichnungsanweisungen ausgeführt werden. Jedesmal, wenn ein Graphikkontext geladen wird, werden alle Anweisungen in der Initialisierungsliste ausgeführtf, wobei sie nicht verbraucht werden. Die Initialisierungsliste wird entweder durch einen direkten Speicherzugriff von den Host- und Steuerprozessoren oder durch Anweisungen modifiziert, die vom Wiedergabeprozessor 36 ausgeführt werden. Somit bestimmt der Requester die Art und den Umfang des für einen Bitraster-Graphikkontext erforderlichen Zustands durch die Verwendung seiner Initialisierungsliste.
Ein Bitraster-Graphikkontext stellt eine Verarbeitungsumgebung ähnlich derjenigen einer Mehrzweck-Lade/Speicher- Architektur dar. In dieser Umgebung besitzt jeder Graphikkontext einen aktuellen Satz von Mehrzweck-Registern - insgesamt 32 Register. Der Inhalt der Mehrzweck- Register muß über die Lebensdauer des Graphikkontextes garantiert verträglich sein. Im Vergleich dazu bleibt der Hardwarekontext zwischen einer Ausführung eines Graphikkontextes und einer weiteren nicht garantiert verträglich, wobei als Ergebnis der Hardwarekontext verträglich gemacht werden muß, wenn ein Graphikkontext geladen wird.
Normalerweise wird ein Register vom Wiedergabeprozessor 36 verwendet, wenn dies von einer Anweisung explizit angewiesen wird. Der Wiedergabeprozessor 36 benötigt jedoch Zugriff auf einige Daten, während er einen Graphikkontext lädt und ausführt. Auf diese Daten wird während der Ausführung eines Graphikkontextes implizit zugegriffen, wobei er bestimmten Registern statisch zugewiesen wird. Der Initialisierungslistenzeiger ist ein Beispiel für die Daten, die der Wiedergabeprozessor 36 verwendet, während er einen Graphikkontext lädt, wobei der Wiedergabeprozessor 36 annehmen kann, daß er diesen Zeiger in Register 2 findet, obwohl Register 2 in jeder Hinsicht ein Mehrzweck- Register ist.

DURCHQUERUNG

Graphikkontexte sind in Datenstrukturen gespeichert, die für eine 3-D-Anwendung von der Strukturabarbeitungsvorrichtung und für eine Bitraster-Anwendung vom Wiedergabeprozessor 36 durchquert werden. Dies deutet an, daß der Wiedergabeprozessor 36 zwei Rollen spielt: er ist eine Rastermaschine und eine Bitraster-Graphikdatenstruktur- Abarbeitungsvorrichtung. Alle Bitraster-Graphikkontext- Datenstrukturen sind mit einem Bitraster-Datenstrukturstamm (Bitraster-Stamm) verbunden, während alle 3-D-Graphikkontext-Datenstrukturen mit einem 3-D-Datenstrukturstamm (3-D-Stamm) verbunden sind. Sowohl Zeiger auf den Bitraster-Stamm als auch Zeiger auf den 3-D-Stamm befinden sich im reservierten Strukturspeicher 26.
Durchquerung ist der Ausdruck, der für die Art verwendet wird, wie eine Klasse von Graphikkontexten zur Ausführung ausgewählt wird. Eine Liste von Graphikkontexten wird durchquert, indem auf eine serielle Weise die Liste durchschritten und jeder Kontext gesichtet wird. Während jeder Sichtung wird bestimmt, ob ein Graphikkontext eine Ausführung erfordert, wobei dann, wenn dies der Fall ist, der Kontext geladen und ausgeführt wird.
Es können zu jedem gegebenen Zeitpunkt bis zu drei Durchquerungen ablaufen: eine 3-D-Durchquerung mit niedriger Priorität, eine Bitraster-Durchquerung mit niedriger Priorität und eine Bitraster-Durchquerung mit hoher Priorität, obwohl zu jedem gegebenen Zeitpunkt nur eine der drei ausgeführt werden kann. Eine Durchquerung ist entweder inaktiv, aktiv oder zurückgestellt. Eine Durchquerung ist anfangs inaktiv und wird durch Verwendung eines Signalmechanismus aktiviert. Wenn sie aktiviert ist, wird der erste Graphikkontext in der Liste gesichtet. Eine Durchquerung kann zurückgestellt werden, wenn eine weitere Durchquerung aktiviert oder fortgesetzt werden muß. Wenn eine zurückgestellte Durchquerung aktiviert wird, wird der aktuelle Graphikkontext in dieser Durchquerung gesichtet. Eine Durchquerung wird inaktiv, nachdem alle Graphikkontexte gesichtet worden sind und keine Signale für diese Durchquerung anhängig sind.
Wenn ein Graphikkontext gesichtet wird, werden zwei Bits im Graphikkontext verwendet, um festzustellen, ob der Graphikkontext eine Ausführung erfordert. Das erste Bit zeigt an, daß der Graphikkontext eine Ausführung mit niedriger Priorität erfordert. Das zweite Bit zeigt an, daß der Graphikkontext eine Ausführung mit hoher Priorität erfordert. Die Abarbeitungsvorrichtung prüft und löscht (gleichzeitig) die entsprechenden Bits im ersten Schritt einer Sichtung. Diese Bits sind in den zwei niederwertigen Bits des Registers 1 in einem Graphikkontext angeordnet. Fig. 8 zeigt einen Graphikkontext und ein Durchquerungsmodell.
Eine Bitraster-Durchquerung wird durch die Verwendung von zwei Bits (Niedrigprioritäts-Laufbit und Hochprioritäts- Laufbit) im Bitraster-Stamm und durch die Verwendung des Steuerstatusregisters (CSR) des Wiedergabeprozessors 36 aktiviert. Über das CSR kontrolliert der Host den Wiedergabeprozessor 36. Um eine Bitraster-Durchquerung mit niedriger Priorität zu aktivieren, wird das Niedrigprioritäts-Laufbit gesetzt. Dieses Bit wird vom Wiedergabeprozessor 36 in Abhängigkeit von einer Zeitbasis oder als Anwort auf eine CSR-Berücksichtigung geprüft und gelöscht (gleichzeitig). Die Signalisierung für eine Durchquerung mit hoher Priorität wird im wesentlichen in der gleichen Weise durchgeführt, wobei das Hochprioritäts-Laufbit im Bitraster-Stamm verwendet wird.
Eine Transaktion ist eine Serie von Anweisungen, die eine Operation oder ein Programm umfassen; Anweisungen in einer Transaktion werden zueinander synchron ausgeführt, können jedoch asynchron zu Anweisungen in anderen Transaktionen ausgeführt werden. Mehrfachtransaktionen werden synchron zu einem Graphikkontext oder asynchron in mehreren Graphikkontexten ausgeführt. Eine Transaktion kann explizit beendet werden, indem die Transaktionsende-Anweisung verwendet wird. Eine Bitraster-Transaktion wird implizit beendet, wenn die Anweisungswarteschlange ausgegeben ist.
Eine Transaktion kann den Wiedergabeprozessor 36 für eine bestimmte Zeitspanne sperren, um normalerweise eine bestimmte Art von Datenverträglichkeit zu erhalten. Dies wird durch Verwenden von Sperr- und Freigabeanweisungen bewerkstelligt. Während der Wiedergabeprozessor 36 gesperrt ist, kann die aktuelle Durchquerung nicht zurückgestellt werden, wobei der aktuelle Graphikkontext weiter ausgeführt wird, bis eine Freigabeanweisung erreicht wird.
Der Wiedergabeprozessor 36 wechselt zwischen Ausführungsanweisungen von Bitraster-Graphikkontexten und Ausführungsanweisungen von 3-D-Graphikkontexten. 3-D-Anweisungen werden aus der Geometrie-Pipeline entnommen. Im allgemeinen besitzen 3-D-Graphikkontexte mit niedriger Priorität und Bitraster-Graphikkontexte mit niedriger Priorität die gleiche Priorität. Die folgenden Regeln werden verwendet, um eine Einteilungsstrategie zu verwirklichen, die eine Ausgewogenheit zwischen der 3-D-Graphikausführung und der Bitraster-Graphikausführung sicherstellt.
- Eine Bitraster-Durchquerung wird anhängig, wenn eines der Laufbits im Bitraster-Stamm gesetzt ist.
- Eine anhängige Bitraster-Durchquerung mit hoher Priorität wird sobald wie möglich eingeleitet: zu jedem Zeitpunkt während einer 3-D-Transaktion oder zwischen irgendwelchen zwei Bitraster-Transaktionen mit niedriger Priorität.
- Eine Bitraster-Durchquerung mit hoher Priorität durchquert ohne Unterbrechung alle Bitraster-Graphikkontexte vom ersten bis zum letzten.
- Eine anhängige Bitraster-Durchquerung mit niedriger Priorität wird eingeleitet, nachdem eine 3-D-Rahmenende-Anweisung empfangen wird, oder unmittelbar nachdem die aktuelle 3-D-Transaktion im Anschluß an ein VSYNC beendet wird.
- Eine Bitraster-Durchquerung mit niedriger Priorität durchquert alle Bitraster-Graphikkontexte vom ersten bis zum letzten, kann jedoch mehrmals zurückgestellt und fortgesetzt werden. Nach einem VSYNC wird eine Durchquerung zurückgestellt und in den anhängigen Zustand zurückversetzt. Während dieser Zurückstellung wird die Ausführung von anhängigen 3-D-Transaktionen eingeleitet.
- Ein Bitraster-Graphikkontext wird anhängig, wenn entweder sein niedriges oder sein hohes Laufbit gesetzt ist.
- Ein anhängiger Bitraster-Graphikkontext mit hoher Priorität wird immer ausgeführt, wenn er durchquert wird.
- Ein anhängiger Bitraster-Graphikkontext mit niedriger Priorität wird nur dann ausgeführt, wenn er bei niedriger Priorität durchquert wird.
- Wenn die Anzahl der in einer einzigen Sichtung eines Graphikkontextes ausgeführten Anweisungen eine im Bitraster-Stamm spezifizierte Grenze überschreitet, wird der Graphikkontext zurückgestellt und anhängig gemacht (neu eingeteilt). Die Durchquerung fährt dann mit dem nächsten Graphikkontext fort.
- Die Ausführung eines Bitraster-Graphikkontextes wird beendet, wenn die Anweisungswarteschlange vollständig ausgegeben worden ist.
- Wenn der Wiedergabeprozessor 36 von einem Graphikkontext gesperrt wird, wird jede Einteilung ausgesetzt, bis eine Freigabeanweisung erreicht wird. Wenn die Anweisungswarteschlange vollständig ausgegeben worden ist, versucht der Wiedergabeprozessor 36 die Anweisungswarteschlange erneut fortzusetzen, bis eine Freigabeanweisung erreicht wird. Bei jedem Neudurchlauf wartet der Wiedergabeprozessor 36 5 µs, um eine Busblockierung zu vermeiden.
Es folgt ein Beispiel eines Einteilungsalgorithmus, der vom Wiedergabeprozessor 36 verwendet wird. Dieser Algorithmus implementiert die obenbeschriebene Einteilungs-Strategie.
Die Neuemteilung stellt die Ausführung von Anweisungen in einem Graphikkontext bis zur nächsten Durchquerung zurück Eine Neuemteilung erfordert, daß sowohl das Graphikkontext-Laufbit als auch das Global-Laufbit gesetzt sind. Nach dem Setzen dieser Bits fährt die Durchquerung mit dem nächsten Graphikkontext fort.
Der Wiedergabeprozessor 36 hält einen Durchquerungszähler im Bitraster-Stamm. Der Durchquerungszähler wird jedesmal dann inkrementiert, wenn eine Bitraster-Durchquerung mit niedriger Priorität abgeschlossen ist. Requester können diesen Zähler verwenden, um festzustellen, ob eine Bitraster-Durchquerung mit niedriger Priorität stattgefunden hat. Er kann nicht als Garantie dafür verwendet werden, daß der Wiedergabeprozessor 36 einen gegebenen Graphikkontext bedient hat, er kann jedoch verwendet werden, um zu garantieren, daß der Wiedergabeprozessor 36 nicht momentan auf eine Struktur zugreift, die vom Zugriff ge trennt worden ist. Somit kann ein Requester den Durchquerungszähler verwenden, um unverkettete Pakete für eine zukünftige Speicherbereinigung zu markieren.
Fig. 9 zeigt die Bitraster-Stammdatenstruktur. (Es ist zu beachten, daß angenommen wird, daß sich die Durchquerung im inaktiven Zustand befindet.) Im folgenden sind Beschreibungen der Inhalte der Datenstrukturen aufgelistet.
- Status - 32-Bit-Feld, das Bits enthält, die für die Bitraster-Durchquerung verwendet werden. Die untenstehende Tabelle enthält Definitionen für die Bits in diesem Feld.
- Current - ein Zeiger auf den vorher ausgeführten Bitraster-Graphikkontext mit niedriger Priorität. Wenn die Bitraster-Durchquerung mit niedriger Priorität inaktiv ist, zeigt er auf First.
- First - ein Zeiger auf den ersten Bitraster-Graphikkontext.
- Last - ein Zeiger auf dem letzten Bitraster-Graphikkontext.
- Command-Limit - eine vorzeichenlose ganze Zahl, die die maximale Anzahl von Anweisungen spezifiziert, die in einem Graphikkontext während irgendeines gegebenen Einteilungszyklus ausgeführt werden dürfen.
- Count - eine vorzeichenlose ganze Zahl, die die Bitraster-Durchquerungen mit niedriger Priorität zählt, die stattgefunden haben.
Der Bitraster-Graphikkontext ist eine Datenstruktur. (Es ist zu beachten, daß keine der in der Anweisungswarteschlange dargestellten Anweisungen ausgeführt worden ist.)
- Next - ein Zeiger auf den nächsten Bitraster-Graphikkontext.
- Status - ein Bitfeld, das Bits enthält, die für die Bitraster-Durchquerung verwendet werden. Die folgende Tabelle enthält Definitionen für jedes Bit in diesem Bitfeld.
- Init - ein Zeiger auf eine Liste von Anweisungen, die die Intitialisierungsliste bilden.
- Current - ein Zeiger auf die vorher ausgeführte Bitraster-Graphikanweisung. Wenn die Bitraster-Durchquerung mit niedriger Priorität inaktiv ist, zeigt er auf First.
- First - ein Zeiger auf die erste Bitraster-Graphikanweisung.
- Last - ein Zeiger auf die letzte Bitraster-Graphikanweisung.
- Basisregister ist ein Zeiger auf 32 Mehrzweck-Register.
Das Bitraster-Datenformat betrifft die Art der Organisation der Bitrasterdaten im Speicher. Es gibt mehrere Wege, wie ein Bitraster im Speicher organisiert sein kann. Der Mikrocode des Wiedergabeprozessors 36 verwaltet vier Formate:
- Zellenmatrix
- Planar
- Ungepackt-Byte
- Ungepackt-Langwort
Im Zellenmatrixformat ist in einem Langwort eine 2x4x4- Matrix von Pixeldaten enthalten: 2 Bits von 16 Pixeln, 4 Zeilen von 4 Pixeln. Benachbarte Langwörter enthalten in X-Richtung benachbarte Zellen. Fig. 11 zeigt, wie die Bits in einer Zelle den Bits in einem Langwort zugeordnet sind.
Es folgt die zur Beschreibung der Bitspeicherung verwendete Vereinbarung:
Langwort 32 Bits
Wort 16 Bits
Byte 8 Bits
Das Planarformat wird meistens in bestehenden DEC-Arbeitsstationen verwendet. In Planarformat ist 1 Bit von 32 Pixeln (das gleiche Bit in jedem Pixel) in einem Langwort gespeichert. Die Bits 0-31 sind benachbarte Pixel, die im Bitraster von links nach rechts laufen. Bits von nachfolgenden Pixeln auf einer Rasterlinie (von links nach rechts) sind in aufeinanderfolgenden Langwörtern des Speichers enthalten. Der zum Speichern einer Rasterlinie von Pixeln verwendete Speicher ist langwortgepackt. Benachbarte Ebenen von Rasterlinien sind in benachbarten Speicherlinien gespeichert. Dies ist aus dem Standard- Planarbitraster abgeleitet; Daten in Rasterlinien sind normalerweise wortgepackt. Wenn Daten vom Systenspeicher zum Strukturspeicher oder vom Strukturspeicher zum Systemspeicher kopiert werden, muß der Host diesen Unterschied ausgleichen. Der Strukturspeicher ist vom Host byte-adressierbar, jedoch vom Wiedergabeprozessor 36 nur langwort-adressierbar.
Im Ungepackt-Byte-Format enthält ein Bitraster Pixel, die 8 oder weniger Bits tief sind, wobei jedes Pixel, ausgerichtet auf Bit 0, in einem Byte des Speichers enthalten ist; 1 Byte enthält genau ein Pixel. Aufeinanderfolgende Pixel auf einer Rasterlinie (von links nach rechts) sind in aufeinanderfolgenden Bytes des Speichers enthalten. Der zum Speichern einer Rasterlinie von Pixeln verwendete Speicher ist langwortgepackt.
Im Ungepackt-Langwort-Format enthält ein Bitraster Pixel, die 32 oder weniger Bits tief sind, wobei jedes Pixel, ausgerichtet auf Bit 0, in einem Langwort des Speichers enthalten ist; ein Langwort enthält genau ein Pixel. Aufeinanderfolgende Pixel auf einer Rasterlinie (von links nach rechts) sind in aufeinanderfolgenden Langwörtern des Speichers enthalten.
Eine Teilung ist ein Wert, der die relative Speicheranordnung von Daten für Pixel spezifiziert, die geometrisch benachbart sind. Pixeldaten können in X-, Y- oder Z-Richtung benachbart sein. In X-Richtung benachbarte Pixeldaten sind in benachbarten Speicherstellen gespeichert, jedoch sind in den anderen Richtungen benachbarte Pixeldaten in Speicherstellen gespeichert, die um das Maß beabstandet sind, daß entweder durch die Y-Teilung oder Z- Teilung spezifiziert ist. Teilungswerte können aus den Bitrasterabmessungen und dem Format berechnet werden. Teilungswerte sind bei der Implementierung einer bestimmten Anweisung normalerweise ein Artefakt. Für das System der Erfindung wird eine Teilung häufig von der Host-Software berechnet und vom Wiedergabeprozessor 36 verwendet, um eine Anweisung auf niedriger Ebene auszuführen. Dies befreit den Wiedergabeprozessor 36 von der Notwendigkeit, Kenntnis von komplizierten Bitraster-Datenstrukturen zu besitzen.
In allen Bitraster-Formaten, mit Ausnahme von Zellenmatrix, spezifiziert die Y-Teilung, wie man sich von einer Rasterlinle zur nächsten bewegt. Im Planar-Format spezifiziert die Z-Teilung, wie man sich von einer Ebene zur nächsten bewegt. Für das Zellenmatrixformat spezifiziert die Y-Teilung, wie man sich von einer Rasterlinie von Zellen (vier Rasterlinien des Bitrasters) zur nächsten bewegt, während die Z-Teilung spezifiziert, wie man sich von einer Ebene von Zellen (zwei Ebenen des Bitrasters) zur nächsten bewegt.
Ein Anzeigekontext definiert, wie ein rechtwinkliger Bereich, ein Anzeigebereich, auf ein oder mehr Bitraster projiziert wird. Jeder Zeitpunkt, zu dem ein Anzeigebereich in einem Bitraster erscheint, wird als Anzeigeinstanz betrachtet. Eine Anzeigeinstanz spezifiziert das Bitraster, in dem der Anzeigebereich erscheint, den Versatz des Anzeigebereichs im Bitraster, wie der Anzeigebereich gekappt wird (Rechtecke und/oder Fensterebenen) und welches Pixelformat verwendet wird. Die Anzeigekontext- Datenstruktur ist in Fig. 12 dargestellt und wird im folgenden beschrieben.

Zieldatenstruktur

- INSTANCES - ein Langwort, das die Adresse der Anzeigeinstanzliste enthält. Ein Wert von 0 (Nullwert) deutet an, daß der Anzeigekontext derzeit in keinem Bitraster erscheint.
- WIDTH - ein Wort, das die Breite des Anzeigebereichs enthält.
- HEIGHT - ein Wort, das die Höhe des Anzeigebereichs enthält.

Zielinstanz-Datenstruktur

- NEXT - ein Langwort, das die Adresse der nächsten Anzeigeinstanz enthält. Eine Adresse von 0 (Nullwert) zeigt das Ende der Anzeigeinstanzuste an.
- BITMAP - ein Langwort, das die Adresse eines Bitraster-Descriptors enthält. Ein Nullwert gibt das Rahmenpuffer-Bitraster an und ist der einzige Wert, den der Wiedergabeprozessor 36 akzeptiert. Wenn ein Wert ungleich 0 erfaßt wird, ignoriert der Wiedergabeprozessor 36 die Zielinstanz.
- XOFF - ein Wort, das den x-Versatz des Anzeigebereichs vom Ursprung des Bitrasters enthält.
- YOFF - ein Wort, das dem y-Versatz des Anzeigebereichs vom Ursprung des Bitrasters enthält.
-BANK - ein Bitfeld, das spezifiziert, welche Rahmenpufferbänke der Anzeigeinstanz angezeigt werden.
-ZE - ein vorzeichenloses Wort, das die Pixelausdehnung des Anzeigepixels enthält. Derzeit ist dieser Wert auf ein Vielfaches von 4 oder 8 beschränkt.
-ZO - ein vorzeichenbehaftetes Wort, das den Pixelversatz des Anzeigepixels im Bitraster-Pixel enthält. Derzeit ist dieser Wert für Anzeigen mit Ausdehnungen von 4 auf ein Vielfaches von 4 und für Anzeigen mit Ausdehnungen von 8 auf ein Vielfaches von 8 beschränkt.
-ZF - ein vorzeichenloses Wort, das das Anzeigepixelformat enthält. Derzeit spezifiziert ein Wert von ein farbabbildendes Format, während ein Wert von 1 ein Vollfarbenformat spezifiziert.
-PMSK - ein Langwort, das ein Bitfeld enthält, das zum Maskieren von Anzeigepixeldaten während des Schreibens verwendet wird.
-WV - ein vorzeichenloses Wort, das die Hardwarefensternummer enthält, das zur Markierung von Zeichenoperationen verwendet wird.
-WM - ein vorzeichenloses Wort, das die Hardwarefenstermaske enthält, die anzeigt, welche Bits in der Fensternummer verwendet werden.
- RCOUNT - ein Wort, das die Anzahl der kappenden Rechtecke in der Anzeigeinstanz enthält.
- RECTS - eine Matrix von Rechteckdatenstrukturen, wie sie im folgenden definiert sind, die verwendet werden, um Zeichenoperationen für diese Anzeigeinstanz zu kappen. Jedes Rechteck ist relativ zum Ursprung des Anzeigebereichs angegeben. Ein Rechteck spezifiziert, wo das Zeichnen ausgeführt werden soll. Eine leere Rechteckliste spezifiziert, daß keine Zeichnung ausgeführt werden soll.

Rechteckdatenstruktur

- X - ein Wort, das den x-Versatz der oberen linken Ecke eines Kappungsrechtecks spezifiziert.
- Y - ein Wort, das den y-Versatz der oberen linken Ecke eines Kappungsrechtecks spezifiziert.
- W - ein Wort, das die Breite eines Kappungsrechtecks spezifiziert.
- H - ein Wort, das die Höhe eines Kappungsrechtecks spezifiziert.

Claims

1. Verfahren zum Betreiben eines Computergraphik- Untersystems (17), mit den Schritten:

Bereitstellen mehrerer Anwendungsprozesse in einer Host-Zentraleinheit (10);

Betreiben der Host-Zentraleinheit (10) in der Weise, daß sie die Anwendungsprozesse so abarbeitet, daß dadurch einzelne, mit den Anwendungsprozessen in Beziehung stehende Graphikdaten-Strukturen erzeugt werden, wovon jede Graphikdaten und Befehle enthält, die ein von dem Computergraphik-Untersystem (17) anzuzeigendes Objekt repräsentieren, und

ferner Betreiben der Host-Zentraleinheit (10) in der Weise, daß sie die einzelnen Graphikdaten-Strukturen in einer Speichervorrichtung (26) speichert,

ferner mit den Schritten:

Bereitstellen einer Steuerdaten-Struktur, die eine Folge von Durchquerungsanforderungen enthält, wovon jede einen Abarbeitungsanzeiger enthält und eine zugeordnete Graphikdaten-Struktur besitzt;

Betreiben einer Graphikvorrichtung (27) unabhängig von der Host-Zentraleinheit (10) in der Weise, daß sie die Steuerdaten-Struktur wiederholt durchquert, um bestimmte der Durchquerungsanforderungen, die als Antwort auf den Abarbeitungsanzeiger jeder Durchquerungsanforderung abgearbeitet werden sollen, zu identifizieren;

Lesen der Graphikdaten-Struktur, die jeder Durchquerungsanforderung zugeordnet ist, welche für die Abarbeitung identifiziert worden ist, und Senden der Graphikdaten-Struktur an ein Graphik-Untersystem (17) für die Verarbeitung, die Manipulation und die Anzeige; und

wobei die Durchquerungsanforderungsfolge Durchquerungsanforderungen von mehreren Anwendungsprozessen enthält und wobei die Reihenfolge der Durchquerungsanförderungsfolge und die Abarbeitung jeder der Durchquerungsanforderungen durch Betreiben der Host-Zentraleinheit (10) in Zusammenwirkung mit der Graphikvorrichtung (27) bestimmt wird, um:

(i) wahlweise getrennte Durchquerungsanforderun gen für die Einfügung in die Folge als Antwort auf Anforderungen der Anwendungen zu erzeugen, wobei jede der getrennten Durchquerungsanforderungen Informationen hinsichtlich des Modus und des Typs der Durchquerung einer im voraus gewählten Struktur von mehreren Graphikdaten- Strukturen besitzt; und

(ii) die im voraus gewählte Graphikstruktur mit der zugeordneten, getrennten Durchquerungsanforderung zu verknüpfen, indem ein Zeiger auf die Graphikdaten- Struktur bereitgestellt wird.

2. Verfahren nach Anspruch 1, ferner mit den Schritten:

(a) Betreiben der Host-Zentraleinheit (10) in der Weise, daß sie Graphikkontexte erzeugt, wovon jeder ein Graphikattribut und Steuerinformationen enthält, die erforderlich sind, um ein Lesen sowie eine Abarbeitung einer Durchquerung wenigstens einer im voraus gewählten Struktur der Graphikdaten-Strukturen auszuführen;

(b) wobei die Durchquerungsanforderungen Merker in den Graphikkontexten besitzen; und

(c) ferner Betreiben der Host-Zentraleinheit (10) in der Weise, daß sie jeden der Graphikkontexte an die wenigstens eine im voraus gewählte Struktur der Graphikdaten- Strukturen anfügt.

3. Verfahren nach Anspruch 2 und ferner mit den Schritten:

(a) Betreiben der Host-Zentraleinheit (10) in der Weise, daß sie Fenster erzeugt;

(b) Betreiben der Host-Zentraleinheit (10) in der Weise, daß sie Anzeigekontexte erzeugt, wovon jeder Informationen hinsichtlich einer Beschreibung eines im voraus gewählten der Fenster enthält; und

(c) ferner Betreiben der Host-Zentraleinheit (10) in der Weise, daß sie jeden der Anzeigekontexte an wenigstens einen im voraus gewählten der Graphikkontexte anfügt.

4. Verfahren nach einem der Ansprüche 1, 2 oder 3, ferner mit den Schritten:

Speichern der Graphikdaten-Strukturen in der Speichereinrichtung (26) als hierarchische Knotenspeicher Strukturen.

5. Verfahren nach einem der Ansprüche 2 oder 3, ferner mit den Schritten:

(a) Betreiben der Graphikvorrichtung (27) in der Weise, daß sie die Speichervorrichtung (26) in einem Anforderungsprozeß durchquert, um die Existenz von Durchquerungsanforderungen in den Graphikkontexten zu ermitteln; und

(b) danach Betreiben der Graphikvorrichtung (27) in der Weise, daß sie die Speichervorrichtung (26) in einem Durchquerungsprozeß durchquert, um die Graphikdaten- Strukturen in Übereinstimmung mit der entsprechend dem Anforderungsprozeß des Schrittes (a) ermittelten Durchquerungs anforderung zu durchqueren.

6. Verfahren nach Anspruch 2, ferner mit den Schritten:

(a) Kompilieren einer Liste in der Speichervorrichtung (26) eines einzelnen Falls aus jedem der Graphikkontexte, wobei jeder der Fälle einen Zeiger auf den entsprechenden Graphikkontext enthält; und

(b) Verwenden der Liste, um die Speichervorrichtung (26) zu durchqueren.

7. Computergraphiksystem, mit einer Host- Zentraleinheit (10), die mehrere Anwendungsprozesse besitzt, wobei die Host-Zentraleinheit (10) in der Weise arbeitet, daß sie die Anwendungsprozesse so abarbeitet, daß einzelne Graphikdaten-Strukturen erzeugt werden, wovon jede Graphikdaten und Befehle enthält, die ein durch das Computergraphiksystem anzuzeigendes Objekt repräsentieren, und einer Speichervorrichtung (26), die mit der Host-Zentraleinheit (10) verbunden ist, wobei die Host- Zentraleinheit in der Weise arbeitet, daß sie die einzelnen Graphikdaten-Strukturen in der Speichervorrichtung (26) speichert;

ferner mit:

(a) einem Graphikuntersystem (17), das mit der Host-Zentraleinheit (10) verbunden ist; wobei das Graphik-Untersystem (17) so arbeitet, daß es Graphikdaten verarbeitet und anzeigt;

(b) wobei das Graphik-Untersystem (17) eine mit der Speichervorrichtung (26) verbundene Graphikvorrichtung (27) besitzt,

wobei die Graphikvorrichtung (27), die unabhängig von der Host-Zentraleinheit (10) betrieben wird, eine Steuerdaten-Struktur wiederholt durchquert, um bestimmte von Durchquerungsanforderungen zu identifizieren, die als Antwort auf einen Abarbeitungsanzeiger jeder Durchquerungsanforderung abgearbeitet werden sollen;

wobei die Steuerdaten-Struktur eine Folge von Durchquerungsanforderungen enthält, wovon jede einen Abarbeitungsanzeiger enthält und eine zugeordnete Graphikdaten-Struktur besitzt;

wobei die Graphikvorrichtung (27) die Graphikdaten-Struktur liest, die jeder Durchquerungsanforderung zugeordnet ist, welche für die Abarbeitung identifiziert wird, und die Graphikdaten-Struktur an das Graphik- Untersystem (17) sendet, um sie zu verarbeiten, zu manipulieren und anzuzeigen;

wobei die Durchquerungsanforderungsfolge Durchquerungsanforderungen von mehreren Anwendungsprozessen enthält,

(c) die Graphikvorrichtung (27) und die Host- Zentraleinheit (10) in der Weise zusammenwirken, um die Durchquerungsanforderungsfolge zu ordnen und um jede der Durchquerungsanforderungen abzuarbeiten und

(i) um als Antwort auf Anforderungen der Anwen dungen wahlweise getrennte Durchquerungsanforderungen für die Einfügung in die Folge zu erzeugen, wobei jede der getrennten Durchquerungsanforderungen Informationen hinsichtlich des Modus und des Typs der Durchquerung einer im voraus gewählten Struktur von mehreren Graphikdaten- Strukturen besitzt; und

(ii) um die im voraus gewählte Graphikstruktur mit der zugeordneten getrennten Durchquerungsanforderung zu verbinden, indem ein Zeiger auf die Graphikdaten- Struktur geschaffen wird.

8. Computergraphik nach Anspruch 7, bei dem die Zentraleinheit (10) in der Weise arbeitet, daß sie Graphikkontexte erzeugt, wovon jeder ein Graphikattribut und Steuerinformationen enthält, die erforderlich sind, um ein Lesen und ein Abarbeiten wenigstens einer im voraus gewählten Struktur der Graphikdaten-Strukturen auszuführen, und daß sie jeden der Graphikkontexte an die wenigstens eine im voraus gewählte Struktur der Graphikdaten- Strukturen anfügt.

9. Computergraphiksystem nach Anspruch 8, bei dem die Durchquerungsanforderungen Merker in den Graphikkontexten enthalten.

10. Computergraphiksystem nach einem der Ansprüche 8 oder 9, bei dem die Zentraleinheit (10) in der Weise arbeitet, daß sie Fenster und Anzeigekontexte erzeugt, wobei jeder der Anzeigekontexte Informationen hinsichtlich einer Beschreibung eines im voraus gewählten der Fenster enthält, und daß sie jeden der Anzeigekontexte an wenigstens einen im voraus gewählten der Graphikkontexte anfügt.

11. Computersystem nach Anspruch 7, bei dem die Zentraleinheit (10) die Graphikdaten-Strukturen in der Speichervorrichtung (26) als hierarchische Knotenspeicher- Strukturen speichert.