DE69530149T2

DE69530149T2 - Effizientes Verfahren zum Interpretieren graphischer Programmiersprache

Info

Publication number: DE69530149T2
Application number: DE69530149T
Authority: DE
Inventors: Timothy Merrick Long; George Politis
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1994-07-25
Filing date: 1995-07-24
Publication date: 2003-12-11
Anticipated expiration: 2015-07-25
Also published as: EP0694881B1; JPH08110953A; AUPM704494A0; US6011919A; EP0694881A3; EP0694881A2; JP3618839B2; HK1013704A1; DE69530149D1

Description

Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf die Erzeugung von computergenerierten Bildern sowohl in der Form von Stehbildern als auch Videobildern und betrifft insbesondere den Zusammensetzungsprozeß der Erzeugung eines aus mehreren Unterkomponenten bestehenden Bilds.

Stand der Technik

Computergenerierte Bilder bestehen typischerweise aus vielen sich unterscheidenden Komponenten oder graphischen Elementen, die miteinander "zusammengesetzt" oder gerendert werden, um ein endgültiges Bild zu erzeugen. Ein Bild wird in seine Elementarbestandteile aufgeteilt, so daß sie unabhängig gerendert werden können, wodurch wegen der Verwendung von kleineren Bildfragmenten potentiell große Mengen von Zeit gespart werden. Jedem Element oder Objekt sind spezielle Matte- oder "Alpha-Kanal"-Informationen zugeordnet, die im allgemeinen Abdeckungsinformationen umfassen, die die Form und transparente Natur des Elements bezeichnen. Die Matte- oder Alpha-Kanal-Informationen werden normalerweise für jedes Bildelement getrennt gespeichert. Jedes Bildelement speichert normalerweise zusätzlich die Farbkomponenten (z. B. Rot, Grün, Blau (RGB)), ebenfalls für jedes Bildelement. Daher kann jedes Bildelement eines Elements durch das Quadrupel (R, G, B, α) dargestellt werden, wobei α die Transparenz eines Elements darstellt und allgemein als der "Alpha"- oder Opazitätskanal bekannt ist. Als ein Beispiel kann dann, wenn Schwarz durch die RGB-Farbkomponenten (0,0,0) dargestellt wird, die Farbe Schwarz durch das Quadrupel (0,0,0,1) dargestellt werden, und eine klare oder vollständig transparente Farbe kann durch das Quadrupel (0,0,0,0) dargestellt werden.
Weiterhin ist es gelegentlich vorteilhaft, die Farbkomponenten mit ihrer Opazität "vorzumultiplizieren". In diesem Fall wird die Farbe (R,G,B) durch (R,G,B)(αR, αG, αß) dargestellt.
Nachstehend auf Fig. 1 bis 3 Bezug nehmend ist nachstehend ein einfaches Beispiel für die Bildzusammensetzung gezeigt. In Fig. 1 ist ein Beispiel für ein kreisförmiges graphisches Element 1 gezeigt, dessen Umriß durch die Kante des Kreises definiert ist. Innerhalb des Kreises ist eine spezielle Farbe oder Variation davon 2 definiert. Von dem Äußeren 3 des kreisförmigen Rands wird es angenommen, daß es von unendlicher Ausdehnung ist und derart definiert ist, daß es einen α-Wert von 0 (d. h. unsichtbar) annimmt. In Fig. 2 ist ein zweites kreisförmiges graphisches Element 4 mit einer von der Farbe des Elements 1 gemäß Fig. 1 verschiedenen Farbe 5 gezeigt. In Fig. 3 ist ein Beispiel für ein komplizierteres Bild 6 gezeigt, das aus der Zusammensetzung einer Kopie jedes der Elemente 1, 4 gemäß Fig. 1 und 2 auf einer Seite gebildet ist. Ein Überlappungsabschnitt 7 ist derart definiert, daß er eine Kombination der zwei Elemente 1, 4 ist, und nimmt einen Farbwert an, der von den Zusammensetzungsoperatoren abhängt, die die zwei Elemente zur Erzeugung eines komplizierteren Bilds 6 kombinieren.
Thomas Porter und Tom Dufflegen in einem "Compositing Digital Images" betitelten, in Computer Graphics, Jahrgang 18, Nr. 3, Juli 1984 auf den Seiten 253-259 erschienenen Artikel ein Verfahren zur Zusammensetzung von Elementen zur Bildung von "Super-Elementen" dar. Porter und Duff erörtern auch Verfahren zur Kombination von zwei Bildern, bei denen beide Bilder einen "α"-Kanal aufweisen. Es sind 13 Hauptzusammensetzungsoperationen zur Kombination von zwei Abschnitten eines einzelnen Bilds vorhanden. Die Funktion jeder der Zusammensetzungsoperationen stellt sich dar wie in einer nachstehenden Tabelle 1 dargelegt, wobei Dc das vormultiplizierte Ziel oder die sich ergebende Farbe ist, Do das Ziel oder der sich ergebende α-Kanal-Wert ist, Ac die vormultiplizierte Bildelementfarbe eines ersten Abschnitts einer ersten Quelle A ist, Ao der dem Bildelement, dessen Farbe Ac ist, entsprechende α-Wert ist, Bc der vormultiplizierte Bildelementfarbwert eines Abschnitts eines Bilds einer zweiten Quelle B ist und Bo der α-Kanal-Wert des dem Bc der Quelle B entsprechenden Bildelements ist.

Tabelle 1: Zusammensetzungsoperationen

OPERATION GLEICHUNG
clear Dc = 0
Do = 0
A Dc = Ac
Do = Ao
B Dc = Bc
Do = Bo
A over B Dc = Ac + Bc(1 - Ao)
Do = Ao + Bo (1 - Ao)
A rover B Dc = Ac(1 - Bo) + Bc (umgekehrter Fall von A over B)
Do = Ao (1 - Bo) + Bo
A in B Dc = AcBo
Do = AoBo
A rin B Dc = AoBc (umgekehrter Fall von A in B)
Do = AoBc
A out B Dc = Ac(1 - Bo)
Do = Ao (1 - Bo)
A rout B Dc = Bc(1 - Ao) (umgekehrter Fall von A out B)
Do = Bo (1 - Ao)
A atop B Dc = AcBo + Bc(1 - Ao)
Do = AoBo + Bo(1 - Ao)
A ratop B Dc = Ac(1 - Bo) + BcAo
Do = Ao(1 - Bo) + BoAo
A xor B Dc = Ac (1 - Bo) + Bc (1 - Ao)
Do = Ao (1 - Bo) + Bo (1 - Ao)
A plusW B Dc = Ac + Bc (mit Dc "umlaufend")
Do = Ao + Bo (mit Do "umlaufend")
A plusC B Dc = Ac + Bc (mit Dc "festgeklemmt")
Do = Ao + Bo (mit Do "festgeklemmt")
In der Tabelle 1 sind verschiedene Verfahren zur Kombination von zwei verschiedenen Bildern miteinander unter Verwendung von verschiedenen Operatoren gezeigt. Operatoren zusätzlich zu den vorstehend verwendeten sind möglich. Die zusätzlichen Operatoren können hauptsächlich zur Realisierung spezieller Effekte verwendet werden.
Die "Umlauf"-Natur des Operators "plusW" bedeutet, daß man dann, wenn z. B. die Addition von Ac + Bc größer als ein maximaler Wert einer Farbkomponente ist, den Wert "umlaufen läßt", um wieder unter Bezugnahme auf den minimalen Wert in dem Farbraum zu beginnen. Alternativ umfaßt der durch "plusC" verwendete Prozeß des "Festklemmens" ein Festklemmen der Addition von z. B. Ac + Bc auf dem maximalen Wert einer Farbkomponente, wenn die Addition größer als diese Komponente ist.
Nachstehend auf Fig. 4 Bezug nehmend sind verschiedene Beispiele für das endgültige Bild gezeigt, das erzeugt wird, wenn verschiedene Operationen wie in der Tabelle 1 dargelegt bei der Zusammensetzung von zwei vollständig opaken Kreisen A und B verwendet werden. Es ist zu beachten, daß die Operatoren "r_über" bzw. "rover", "r_ein" bzw. "rin", "r_aus" bzw. "rout" und "ra_oben" bzw. "ratop" äquivalent zu dem Tauschen der Operanden für den "r" - Operator (Umkehroperator) und jeweiligen Anwenden des entsprechenden Operators "über" bzw. "over", "ein" bzw. "in", "aus" bzw. "out" und "a_oben" bzw. "atop" sind.
In jüngster Zeit sind Graphiksprachen in der Form von Seitenbeschreibungssprachen wie beispielsweise POSTSCRIPT (Warenzeichen) verfügbar geworden. Diese Sprachen bieten die volle Funktionalität einer relativ komplizierten Programmiersprache, wodurch sie es ermöglichen, komplizierte Bilder über die Verwendung von Gedanken der Iteration, des Steuerablaufs und der prozeduralen Definition von Bildelementen kompakt zu beschreiben. Diese Seitenbeschreibungssprachen wurden entwickelt, um den Anwendungsautor von irgendwelchen geräteabhängigen Einzelheiten von Druckern zu isolieren und dadurch die Portabilität zu unterstützen. Diese Sprachen bieten eine ausgedehnte Unterstützung für Text, Spline-basierte graphische Objekte und abgetastete Bilder. Ein Interpretierer für die Sprache kann daraufhin aufgebaut werden und sich z. B. in einer Druckvorrichtung befinden, was es ermöglicht, ein kompliziertes Bild kompakt darzustellen. Zusätzlich helfen Seitenbeschreibungssprachen bei der Portabilität von einer Ausgabevorrichtung zu einer anderen, da die Interpretation der Sprache geräteunabhängig sein kann. Sprachen wie beispielsweise POSTSCRIPT wurden ursprünglich aufgebaut, um das Erscheinungsbild einer Bitmaskenseite oder eines Bitmaskenbildschirms zu beschreiben, und verwenden bestimmte Graphikprimitive, die auf dem Gedanken des Malens mit opaker Farbe auf dem Bitmaskenbild basieren.
Wie bei den meisten Programmiersprachen bestehen Seitenbeschreibungssprachen häufig aus Operanden und Operatoren, die auf die Operanden einwirken, um neue Ergebnisse oder Effekte zu erzeugen. Die Operanden können gelegentlich fundamentale graphische Einheiten wie beispielsweise eine Linie, einen Bogen, eine Kurve, eine Sammlung von Linien und Splines, eine Folge von Text oder ein abgetastetes Bild umfassen und sind dazu entworfen, daß durch die Operatoren auf ihnen gearbeitet wird. Die Operatoren können in viele verschiedene Kategorien einschließlich der folgenden klassifiziert werden:
1. Operatoren, die derzeitige Eigenschaften von verschiedenen Operanden oder globalen Statusvariablen bestimmen.
2. Operatoren, die die verschiedenen Koordinatensysteme ändern, in denen fundamentale Einheiten zu definieren sind.
3. Pfadoperatoren, die bestimmte grundlegende Einheiten zur Definition verschiedener Pfade aktualisieren, wodurch sie den Aufbau von komplizierten Objekten ermöglichen.
4. Verschiedene "rendernde" Operatoren, die Bilddaten generieren, die schließlich die Farbe der einzelnen Punkte bestimmen, die auf einer Ausgabeseite erscheinen.
5. Eine spezielle Klasse von Operatoren wird normalerweise zur Bestimmung, Modifikation und Auswahl von Text oder Schriftsätzen verwendet. Dies ist durch die spezielle Natur von Zeichenschriftsätzen verursacht, die vorher vorbereitet und ständig verwendet werden.
6. Verschiedene Vorrichtungseinstellungs- und Ausgabeoperatoren, die zur Steuerung der Ausgabe eines Bilds zu einer Anzeigevorrichtung wie beispielsweise einem Drucker oder einem Bildschirm verwendet werden können.
Unglücklicherweise stützen sich Sprachen wie beispielsweise POSTSCRIPT und dergleichen auf ein "Vorrichtungsmodell", das auf das Malen mit opaker Farbe auf einem Bildspeicher oder dergleichen gerichtet ist. Die Verwendung eines Bildspeichers erfordert übermäßige Mengen von Speicher, und mit modernen Abbildungstechniken, die eine Ausgabe mit hoher Qualität erfordern, kann dies häufig dazu führen, daß übermäßige Mengen von Speicher und Berechnung zur Erzeugung eines Bilds benötigt werden. Zusätzlich wird die Ineffizienz bei der Verwendung von Maltechniken mit zunehmenden Ausgabeauflösungen hervorgehoben.
Es ist aus EP-A-0528631 bekannt, Ausdrucksdiagramme bereitzustellen, die einen Bilderzeugungsprozeß darstellen und die graphisch angezeigt werden, um eine interaktive Eingabe durch einen Benutzer zur Erzeugung und Bearbeitung der Ausdrucksdiagramme bereitzustellen. Es ist ebenfalls vorgeschlagen, eine Optimierung durch eine Entfernung eines wiederholten Ausdrucks, eine Entfernung eines nicht erreichbaren Ausdrucks und eine Entfernung eines idempotenten Ausdrucks bereitzustellen, wodurch eine Kompilierung des Ausdrucks in einer effizienteren Form vor der Ausführung ermöglicht wird.
Gemäß der vorliegenden Erfindung wird ein Verfahren zur Interpretation eines Programms für die Erzeugung eines Bilds offenbart, wobei das Bild aus mehreren graphischen Elementen besteht und das Programm in einer graphischen Programmiersprache definiert ist, wobei das Verfahren durch einen Computer ausgeführt wird und die Schritte umfaßt:
(a) Aufbauen zumindest eines Ausdrucksbaums, der die zur Erzeugung des Bilds erforderlichen Operationen beschreibt;
(b) automatisches Ändern zumindest eines Abschnitts des Ausdrucksbaums zur Verringerung einer entsprechenden Ausführungszeit einer von dem Ausdrucksbaum abgeleiteten Folge von Anweisungen ohne eine wesentliche Änderung des durch die Ausführung der Folge von Anweisungen erzeugten Bilds; und
(c) Wandeln des geänderten Ausdrucksbaums in eine entsprechende Folge von Anweisungen zur Erzeugung des Bilds;
dadurch gekennzeichnet, daß der Änderungsschritt die Unterschritte umfaßt:
(b) (i) Bestimmen einer alternativen Form von Ausdruck von Abschnitten des zumindest einen Ausdrucksbaums;
(b) (ii) Schätzen eines Aufwands der Ausführung einer entsprechenden Folge von Anweisungen der alternativen Form von Ausdruck; und
(b) (iii) Ändern des Abschnitts zu der alternativen Form von Ausdruck, wenn der Aufwand der Ausführung der alternativen Form des Abschnitts niedriger als der Aufwand der Ausführung einer gegenwärtigen Form des Abschnitts ist;
wobei der Ausdrucksbaum Blattknoten mit zugeordneten graphischen Elementen und innere Knoten mit zugeordneten Codes zur Kombination graphischer Elemente umfaßt, und wobei die Abschnitte innere Knoten umfassen und der Schätzunterschritt die Unterschritte umfaßt:
(b) (ii) (1) Bestimmen der Größe von abstammenden graphischen Elementen, die den Nachfahren des derzeitigen Knotens entsprechen; und
(b) (ii)(2) Bestimmen des Aufwands der Ausführung aus zumindest der Größe der abstammenden graphischen Elemente.
Die Erfindung wird gemäß den beiliegenden unabhängigen Ansprüchen 1, 8 und 15 ausgeführt.
Andere Ausgestaltungen der Erfindung sind gemäß den beiliegenden Ansprüchen offenbart.

Kurzbeschreibung der Zeichnungen

Das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung ist nachstehend unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen:
Fig. 1 und 2 zwei einfache graphische Elemente veranschaulichen;
Fig. 3 die Zusammensetzung von graphischen Elementen veranschaulicht;
Fig. 4 verschiedene Zusammensetzungsoperatoren und die daraus folgende Ausgabe wie bei dem bevorzugten Ausführungsbeispiel verwendet veranschaulicht;
Fig. 5 bis 9 den Aufbau eines Ausdrucksbaums für eine erste Folge von Angaben veranschaulichen;
Fig. 10 bis 14 den Zusammensetzungsprozeß der ersten Folge von Angaben veranschaulichen;
Fig. 15 ein sich aus einer zweiten Folge von Angaben ergebendes endgültiges Bild veranschaulicht;
Fig. 16 den Ausdrucksbaum der zweiten Folge von Angaben veranschaulicht;
Fig. 17 den bei dem Ausdrucksbaum ausgeführten Ausdehnungsbereichsprozeß bzw. Bounding-Box-Prozeß veranschaulicht;
Fig. 18 eine weitere Bounding-Box-Minimierung veranschaulicht, die gemäß dem bevorzugten Ausführungsbeispiel ausgeführt wird;
Fig. 19 zwei graphische Elemente veranschaulicht, die unter Verwendung des Operators "in" zu kombinieren sind;
Fig. 20 und 21 ein erstes Verfahren zur Kombination der graphischen Elemente gemäß Fig. 19 veranschaulichen;
Fig. 22 ein zweites Verfahren zur Kombination der graphischen Elemente gemäß Fig. 19 veranschaulicht;
Fig. 23 ein erstes Verfahren zur Wandlung eines Ausdrucksbaums in entsprechende "Zwischenstufen"- Anweisungen veranschaulicht;
Fig. 24 ein zweites Verfahren zur Wandlung eines Ausdrucksbaums in entsprechende Anweisungen veranschaulicht;
Fig. 25 eine bei einem Ausdrucksbaum auszuführende erste Optimierung veranschaulicht;
Fig. 26 eine bei einem Ausdrucksbaum auszuführende zweite Optimierung veranschaulicht;
Fig. 27 eine dritte Optimierung veranschaulicht, die bei einem Ausdrucksbaum ausgeführt werden kann;
Fig. 28 ein erstes Verfahren zur Optimierung eines Abschnitts eines Ausdrucksbaums veranschaulicht;
Fig. 29 ein zweites Verfahren zur Optimierung eines Abschnitts eines Ausdrucksbaums veranschaulicht;
Fig. 30 zwei graphische Elemente und ihre entsprechenden Bounding-Boxen veranschaulicht;
Fig. 31 die Zusammensetzung der zwei graphischen Elemente gemäß Fig. 30 veranschaulicht;
Fig. 32 die verkleinerte Bounding-Box eines der graphischen Elemente gemäß Fig. 30 veranschaulicht;
Fig. 33 eine durch das bevorzugte Ausführungsbeispiel ausgeführte Farboptimierung veranschaulicht;
Fig. 34 eine Computerarchitektur zur Ausführung der Anweisungen des bevorzugten Ausführungsbeispiels veranschaulicht; und
Fig. 35 ein Flußdiagramm enthält, das die Kompilierung und Ausführung von Anweisungen des bevorzugten Ausführungsbeispiels darstellt.

Ausführliche Beschreibung des bevorzugten Ausführungsbeispiels

Bei dem bevorzugten Ausführungsbeispiel weist die beschriebene Programmiersprache die nachstehenden vorteilhaften Merkmale auf:
1. Graphische Elemente und ihre Kombination sind Datentypen der Sprache, und beliebige Kombinationen von graphischen Elementen sind möglich.
2. Graphische Operatoren nehmen graphische Elemente als ihre Operanden und berechnen neue graphische Elemente oder Kombinationen davon.
3. Graphische Objekte können auf die gleiche Weise wie andere Standardsprachendatentypen verwendet werden, wobei sie den Typbeschränkungen von Operatoren unterliegen, mit denen sie verbunden sind (z. B. arbeitet der Divisionsoperator lediglich auf arithmetischen Operanden, der Zuweisungsoperator arbeitet jedoch für irgendwelche Operandentypen).
4. Alle graphischen Elemente und die Ergebnisse von Kombinationen von graphischen Elementen unter Verwendung von graphischen Operatoren sind geeignete Operanden für weitere graphische Operationen.
5. Ein Bild kann zur Ausgabe erzeugt werden, indem ein spezifisches graphisches Element gerendert wird, das durch die Ausführung des Seitenbeschreibungsprogramms erzeugt worden ist.
Bei dem bevorzugten Ausführungsbeispiel sind die grundlegenden graphischen Elemente aus den nachstehenden "Primitivtypen" aufgebaut:
1. Text einschließlich einer Vielfalt von Schriftsätzen, die bei verschiedenen Größen bestimmt sind.
2. Objekte, deren Umrisse durch Spline-Daten definiert sind, die auch als Pfade bekannt sind.
3. Bildelementdaten wie beispielsweise abgetastete Bilder oder vorher zusammengesetzte Bilder, die selbst graphische Elemente bilden.
4. Ein als "alles" bekanntes graphisches Element, das als der Hintergrund einer Seite verwendet, wird und zumindest so groß wie das Bild, das erzeugt wird, sein sollte.
Farbliche und textuelle graphische Elemente können Eigenschaften aufweisen, die umfassen:
(a) Farbe, ob eine feste Farbe, eine Mischung zwischen zwei Farben oder eine sich wiederholende, bildelementbasierte Kachel,
(b) Opazität oder α-Kanal-Daten, mit den gleichen möglichen Optionen der Variation wie Farbdaten, und
(c) Füllende und/oder streichende Daten, die das Rendern der Pfade oder des textuellen graphischen Elements steuern. Ein "graphischer Kontext" liefert die Eigenschaftswerte, die jedem graphischen Element zuzuordnen sind. Wenn ein neues Element erzeugt wird, finden die Eigenschaftswerte in dem graphischen Kontext zu der Zeit der Erzeugung bei dem neuen graphischen Element Anwendung.
Die Programmiersprache selbst umfaßt daher die nachstehenden Datentypen:
1. Textobjekte, die den Schriftsatz, die Größe, die Plazierung und andere gewünschte Eigenschaften jedes Zeichens definieren, aber nicht die Farb-, Opazitäts-, Füll- oder Streichparameter des Texts.
2. Pfadobjekte, die den Umriß der Form eines speziellen Objekts definieren, aber nicht seine Farb-, Opazitäts-, Füll- oder Streichparameter.
3. Graphische Elemente, die Bildelementdaten, ein graphisches Element "alles", die Zusammensetzung einer Anzahl von anderen graphischen Elementen miteinander durch einen Zusammensetzungsoperator zum Gewinnen eines graphischen Elements oder ein Textobjekt oder ein Pfadobjekt, das in eine entsprechende Bildelementform gerendert worden ist, darstellen.
Die Bildzusammensetzung stellt einen Satz von binären Operatoren bereit, die Bilder als Operanden nehmen und ein Bild als ein Ergebnis erzeugen. Ein Bild ist derart definiert, daß es sowohl Farbinformationen als auch α- Kanal-Informationen oder Opazitätskanalinformationen bei jedem Bildelement aufweist, obwohl in einigen Situationen die Farbinformationen eines graphischen Elements nicht verwendet werden. Um dazu in der Lage zu sein, graphische Elemente aller Typen zu kombinieren oder zusammenzusetzen, werden alle graphischen Elemente einschließlich graphischer Elemente Text, Pfad und "alles" so behandelt, als ob sie in Bildelementbilder abtastgewandelt werden, bevor sie miteinander zusammengesetzt werden. Zusätzlich werden die graphischen Elemente dann, wenn sie Operanden bilden, so behandelt, als ob sie von theoretisch unendlicher Ausdehnung wären. Jedes Bildelement außerhalb der Grenze eines graphischen Elements wird so behandelt, als ob es vollständig transparent wäre. Diese Erweiterung jedes graphischen Elements wird realisiert, um es zu ermöglichen, ein Ergebnis zu definieren, wenn ein Bildelement sich innerhalb der normalen Ausdehnung eines Operanden, aber nicht des anderen Operanden befindet. Zusätzlich erfordern es einige spezielle Operationen immer, daß die Farbe definiert wird, so daß vollständig transparente Bildelemente eine Farbe annehmen, wie sie durch die Nullkomponenten in dem Renderfarbraum dargestellt ist.
Die Rendersprache des bevorzugten Ausführungsbeispiels kann auf eine Anzahl von verschiedenen Weisen ähnlich der Weise einer normalen Computersprache "ausgeführt" werden. Computersprachen werden normalerweise durch einen entsprechenden Computer über Einrichtungen zur "Interpretation" oder "Zusammenstellung" bzw. "Kompilierung", die dem Fachmann auf dem spezialisierten Fachgebiet des Schreibens von Computersprachenkompilierern bekannt sind, "ausgeführt".
Sowohl Interpretierer als auch Kompilierer bauen normalerweise einen Analyse- oder Ausdrucksbaum für die Sprachenbeschreibung auf, der aus einer höchstwahrscheinlich kontextfreien Grammatik aufgebaut wird, die die Sprache definiert. Für eine weitere Erläuterung von Interpretierern und Kompilierern wird auf einen Standardtext wie beispielsweise "Compilers Principles, Techniques, and Tools" von Aho, Sethi und Ullman, 1986, erhältlich von Addison-Wesley Publishing Company, Reading, Massachusetts Bezug genommen.
Die Ausführung der Programme der Programmiersprache des bevorzugten Ausführungsbeispiels wird für die Geschwindigkeit, die Größe und die Leichtigkeit der Realisierung durch einen Interpretierer ausgeführt.
Für jede Angabe in der Programmiersprache analysiert der Interpretierer die Angabe und wandelt die Angabe in eine ausführbare Form. Diese ausführbare Form wird daraufhin ausgeführt. Während der Ausführung dieser ausführbaren Form werden Operationen ausgeführt, die bei graphischen Elementen Anwendung finden. Eine Anzahl von verschiedenen Techniken kann zur Ausführung derselben verwendet werden, einschließlich einer unmittelbaren Ausführung und einer aufgeschobenen Ausführung.

Unmittelbare Ausführung

Für jede auf graphische Elemente angewendete Operation wird Rasterspeicher erzeugt, der zum Halten des sich ergebenden Bildelementbilds ausreicht, und die Operation wird zur Kombination ihrer Operanden verwendet, um die Bildelementdaten des ausgegebenen Rasterbildbereichs zu erzeugen. Dieser Rasterbildbereich wird daraufhin das graphische Element, das das Ergebnis der Operation ist. Wenn eine Renderoperation ausgeführt wird, werden die Rasterbildelemente des gewünschten graphischen Elements zu der Ausgabevorrichtung übertragen.
Diese Technik weist den Nachteil auf, daß große Mengen von Speicher erforderlich sein können, falls im Verlauf der Ausführung eines Programms Viele dazwischenliegende graphische Elemente verwendet werden. Sie weist auch den weiteren Nachteil auf, daß wenige nachfolgende Optimierungen möglich sind, da keine Informationen über die nachfolgende Verwendung eines graphischen Elements verfügbar sind, wenn es berechnet oder erzeugt wird.
Ein Beispiel für die Operation des Interpretierers gemäß dem Modell der unmittelbaren Ausführung ist nachstehend unter Bezugnahme auf Fig. 5 bis 14 beschrieben. Es wird die nachstehende beispielhafte Folge von Anweisungen betrachtet:

Tabelle 2

A = Text("a"); (1)
A: = Text ("b"); (2)
A: = Text("c"); (3)
B = Kreis (); (4)
A = A over B; (5)
In der Programmiersprache des bevorzugten Ausführungsbeispiels weist der Ausdruck "A = B" der Variablen A den Wert von B zu. Der Ausdruck "A: = B" ist eine Kurzschriftform des Ausdrucks von "A = A rover B", wobei "A rover B" das gleiche Ergebnis wie "B over A" erzeugt.
Die Funktion "Text" erzeugt ein Textobjekt, das wie vorher angeführt bei dem bevorzugten Ausführungsbeispiel keine Farb- oder Opazitätsinformationen aufweist und lediglich Zeichen-, Schriftsatz-, Größen- und Positionsinformationen aufweist. Die Angabe A: = Text("b") ist jedoch äquivalent zu "A = A rover Text("b")". Wenn der Operator "rover" auf einen Textoperand angewendet wird, wird der Textoperand zuerst in ein graphisches Element gewandelt. Dies wird erreicht, indem der Text theoretisch gerendert wird, um seine Eigenschaften zu bestimmen. Bei der Ausführung des Funktionsaufrufs "Text" wird der derzeitige Punkt um die sich ergebende Breite der gerenderten Textfolge des graphischen Elements bewegt. Fig. 5 zeigt den entsprechenden Ausdrucksbaum nach dem Abschluß der ersten Anweisung.
Die erste Anweisung, die Anweisung 1 gemäß der Tabelle 2, ist äquivalent zu einer Zuweisung des dem Zeichen 'a' entsprechenden graphischen Elements zu der Variablen A. Das Ergebnis dieser Zuweisung ist in Fig. 10 veranschaulicht.
Die zweite durch den Intepretierer ausgeführte Anweisung, die Anweisung 2, umfaßt ein Rendern des dem Zeichen 'b' neben dem Zeichen 'a' entsprechenden graphischen Elements. Der sich ergebende Ausdrucksbaum nach der Ausführung dieser Angabe stellt sich dar wie in Fig. 6 angegeben, und der Zustand der Variablen A stellt sich dar wie in Fig. 11 angegeben.
Die vorstehende Anweisung 3 umfaßt das Rendern des dem Zeichen 'c' neben den vorher gerenderten Zeichen entsprechenden graphischen Elements. Der entsprechende Ausdrucksbaum für die Folge von Anweisungen (1) bis (3) stellt sich dar wie in Fig. 7 dargestellt, und der Zustand der Variablen A stellt sich dar wie in Fig. 11 angegeben.
Die Anweisung 4 erzeugt ein graphisches Element mit einem Kreis und weist es dem durch die Variable B definierten graphischen Element zu. Der entsprechende Ausdrucksbaum für diese Anweisung stellt sich dar wie in Fig. 8 gezeigt, und der Zustand der Variablen B stellt sich dar wie in Fig. 13 gezeigt.
Die Anweisung 5 umfaßt das Zusammensetzen des graphischen Elements A über das durch das graphische Element B definierte. Fig. 9 veranschaulicht den sich ergebenden Ausdrucksbaum für das graphische Element A nach der Ausführung der Anweisung 5. Der Abschnitt 10 stellt den Ausdrucksbaum gemäß Fig. 7 dar, der der vorherige Ausdrucksbaum für A war, der auf der rechten Seite der Anweisung 5 erscheint. Fig. 14 zeigt den entsprechenden Zustand der Variablen A, wenn das Verfahren der unmittelbaren Ausführung verwendet wird.

Aufgeschobene Ausführung

Ein zweiter Ansatz für die Ausführung des Kompilierers ist das Modell der aufgeschobenen Ausführung. Bei diesem Modell wird für jede auf die graphischen Elemente in der Form von Programmangaben angewendete Operation ein Ausdrucksbaumknoten erzeugt, der die Operation darstellt. Der erzeugte Ausdrucksbaumknoten zeichnet die Operation oder den Operator auf, und die Kinder bzw. Nachfolger des Ausdrucksbaumknotens sind die Operanden der Operation. Der Ausdrucksbaumknoten wird daraufhin das graphische Element, das das Ergebnis der Operation ist. Während die Ausführung von einer Angabe oder mehreren Angaben ausgeführt wird, werden durch vorherige Operationen erzeugte Ausdrucksbäume von Zeit zu Zeit mit Operationen weiter kombiniert, um auf die gleiche Art und Weise wie die in Fig. 5 bis 9 gezeigte kompliziertere Ausdrucksbäume zu erzeugen.
Anschließend wird dann, wenn eine Renderoperation ausgeführt wird, der gewünschte Ausdrucksbaum rekursiv durchlaufen bzw. traversiert, und die gewünschten Operationen werden ausgeführt, um das gewünschte Bild zu erzeugen, das zu der Ausgabevorrichtung übertragen wird.
Diese Technik weist den Vorteil auf, daß Renderoperationen aufgeschoben werden können, bis Informationen über die nachfolgende Verwendung des so erzeugten graphischen Elements bekannt sind. Daher muß kein Speicher zur Speicherung der Rasterbildelemente von graphischen Elementen zugeordnet werden, bis die Programmausführung beendet ist, und es können Optimierungen ausgeführt werden, die die nachfolgende Verwendung von graphischen Elementen berücksichtigen.
Zwei Ansätze können zur Realisierung des Interpretierers angewendet werden:
1. Ein "postfix" oder "stapelspeicherbasierter" Ansatz, bei dem graphische Elemente als Operanden in einen Zusammensetzungsstapelspeicher eingespeichert werden und Operatoren zum Einwirken auf Elemente in dem Stapelspeicher verwendet werden. Somit kann ein binärer Operator die obersten zwei Stapelspeichereinträge entfernen, sie zusammensetzen und das zusammengesetzte Ergebnis zurück in dem Stapelspeicher plazieren. Bei dem Abschluß aller Angaben in der eingegebenen Seitenbeschreibung kann das oberste Ende des Stapelspeichers daraufhin für die Ausgabevorrichtung gerendert werden.
2. Ein "infix" oder "ausdrucksbasierter" Ansatz, bei dem entweder direkt auf primitiven graphischen Elementen gearbeitet werden kann oder diese in Variablen gespeichert werden können. Ein Operator kann primitive graphische Elemente oder vorher in Variablen gespeicherte graphische Elemente oder Unterausdrücke kombinieren, wodurch ein neues graphisches Element erzeugt wird, das in einer Variablen gespeichert oder durch weitere Operationen weiter kombiniert werden kann. Ein einer vordefinierten Variablen, z. B. "Seite", zugewiesenes graphisches Element kann daraufhin für eine Ausgabevorrichtung gerendert werden.
Der Unterschied zwischen den zwei vorstehenden Ansätzen ist analog zu den Unterschieden bei der jeweiligen Fähigkeit eines Kellerautomaten und einer Turingmaschine.
Bei der bevorzugten Realisierung des Interpretierers wird das zweite Modell der aufgeschobenen Ausführung verwendet, und:
1. Graphische Operationen werden aufgeschoben und erzeugen Ausdrucksbäume.
2. Ein "infix" Ansatz wird zur Ausführung von Ausdrucksbäumen verwendet.
3. Alle Objekte mit Pfadumrissen, Zeichen und Bildern werden zuerst theoretisch in fundamentale graphische Elemente gewandelt, die aus einem Bildelementbild von unendlicher Ausdehnung bestehen. Die Zusammensetzung wird daraufhin ausgeführt, indem die Operatoren wie in der Tabelle 1 definiert verwendet werden, die sowohl binäre als auch unäre Operatoren umfassen.
Sobald der Ausdrucksbaum für ein Bild erzeugt worden ist, ist das Bild daraufhin dazu bereit, für die relevante Ausgabevorrichtung "gerendert" zu werden. Unter Verwendung einer vordefinierten Variablen wie beispielsweise "Seite" zur Darstellung des graphischen Elements der Ausgabevorrichtung kann das Ausgabebild gerendert werden, indem der dieser Variablen entsprechende Ausdrucksbaum gerendert wird. Unter der Annahme, daß die Ausgabevorrichtung eine Vorrichtung ist, die ein Ausgabebild Abtastzeile für Abtastzeile annimmt, ist eine Anzahl von verschiedenen Rendertechniken möglich, einschließlich:
1. Für jede Abtastzeile wird der Ausdrucksbaum für die Ausgabevariable traversiert, und das Rendern jedes graphischen Elements und Zusammensetzungsoperators wird wie für die Abtastzeile relevant ausgeführt.
2. Erkennend, daß ein Traversieren eines binären Baums bei jeder Abtastzeile hinsichtlich der Computerzeit ein aufwendiger Prozeß ist, kann zuerst aus dem Ausdrucksbaum eine lineare Renderliste erzeugt werden. Anschließend wird für jede Abtastzeile jedes graphische Element wie erforderlich gerendert, und jede Zusammensetzungsoperation wird wie für die Abtastzeile relevant ausgeführt. Diese Form der Ausführung erfordert es, daß ein Stapelspeicher Zwischenergebnisse hält, die ausgewerteten Unterabschnitten des Ausdrucksbaums entsprechen.
3. Erkennend, daß es ineffizient ist, für jede Abtastzeile die ganze lineare Renderliste abzutasten, kann ein Sortieren der linearen Renderliste durchgeführt werden, wobei die Liste gemäß der Anfangsabtastzeile eines speziellen graphischen Elements sortiert wird. Wenn jede Abtastzeile gerendert wird, kann eine aktive Liste unterhalten werden, die alle die graphischen Elemente der linearen Renderliste enthält, die eine derzeit zu rendernde Abtastzeile beeinflussen. Bei dem Beginn jeder Abtastzeile werden Anweisungen, die bei der Abtastzeile beginnen, in die aktive Liste gemischt, und Anweisungen, die nicht mehr relevant sind, werden aus der aktiven Liste herausgenommen. Dies ist analog zu der Technik des Unterhaltens einer aktiven Liste von Anzeigelistenanweisungen, die in dem Fachgebiet bekannt ist.
Sobald das Konzept des dritten der vorstehenden Ansätze begriffen worden ist, kann zur Unterstützung des Verständnisses des Konzepts die Interpretation der Seitenbeschreibungsprogrammiersprachenangaben mit den durch einen Kompilierer ausgeführten Operationen verglichen werden. Der anfängliche Ausdrucksbaum kann mit einem Analysebaum eines Kompilierers verglichen werden, die Erzeugung der Renderliste kann mit der Codeerzeugungsphase eines Kompilierers verglichen werden, die aus dem Analysebaum erzeugte lineare Renderliste kann mit Assembleranweisungen oder in einigen Kompilierern verwendetem Zwischencode verglichen werden und das Rendern der linearen Renderliste kann mit der Ausführung von Assemblersprachenanweisungen durch einen Computer verglichen werden.
Der Ausdrucksbaum für einen speziellen Satz von Seitenbeschreibungssprachenangaben wird durch den Interpretierer aufgebaut, indem die in der Seitenbeschreibung enthaltenen Angaben ausgeführt werden, einschließlich irgendwelcher "while"-Schleifen, bedingter Angaben und anderer normaler Aufbauten, die in modernen Programmiersprachen wie beispielsweise C, Pascal, Algol usw. bereitgestellt sind und von denen es angenommen wird, daß sie einen Teil der Programmiersprache bilden. Da ein in einer speziellen Variablen gespeicherter Ausdrucksbaum in der Seitenbeschreibung oder in der Seitenbeschreibung von nachfolgenden Seiten in einem Seitenbeschreibungssprachenprogramm wiederverwendet werden kann, ist es sehr wünschenswert, daß ein Ausdrucksbaum von einem externen Standpunkt oder Benutzerstandpunkt aus unverändert gelassen wird. Sobald der Interpretierer den Aufbau des Ausdrucksbaums abgeschlossen hat, sind jedoch Kompiliererstiloptimierungen möglich, die die Struktur des Baums neu anordnen können. Um diese Optimierungen als Teil des Renderprozesses zu ermöglichen, werden daher zwei Sätze von Zeigern in dem Baum verwendet und werden die Benutzerzeiger und die Arbeitszeiger genannt. Wenn der Interpretierer anfänglich den Ausdrucksbaum aus der Seitenlayoutprogrammbeschreibung aufbaut, werden die Benutzerzeiger verwendet. Wenn der das Seitenlayout beschreibende Ausdrucksbaum anschließend zum Rendern verarbeitet wird, können die Arbeitszeiger verwendet werden, was den Benutzersatz von Zeigern intakt läßt.
Sobald der Ausdrucksbaumaufbau abgeschlossen ist, kann der Renderlistenerzeugungsprozeß eingeleitet werden. Dieser Renderprozeß Wird durch die Ausführung einer Anzahl von Optimierungsschritten bei dem Ausdrucksbaum eingeleitet. Diese Schritte sind nachstehend nach der Beschreibung des Renderlistenerzeugungsprozesses beschrieben.
Der Renderlistenerzeugungsprozeß ist analog zu der Erzeugung von Assemblercode oder einem Zwischencodeschritt wie durch normale Kompilierer ausgeführt. Man kann sich Elemente der Renderliste als Anweisungen zur Zusammensetzung eines graphischen Elements oder zur Ausführung eines anderen Prozesses vorstellen.
Es sind zwei Ansätze für die Renderlistenerzeugung vorhanden, von denen einer besser für eine hardwareunterstützte Rendervorrichtung geeignet ist, wobei der andere für eine "Nur-Software"-Realisierung geeignet ist. Beide Ansätze erfordern die Verwendung eines Renderstapelspeichers zur Speicherung der derzeitigen Ergebnisse von Zusammensetzungsoperationen für eine zukünftige Zusammensetzung. Der softwareorientierte Ansatz arbeitet mit dem Renderstapelspeicher mit Anweisungen, die entweder ein graphisches Element in den Stapelspeicher einspeichern oder eine Operation bei den Operanden in dem Stapelspeicher ausführen. Der hardwareunterstütze Ansatz nimmt die Verwendung eines "Akkumulators" an. Anweisungen laden entweder ein graphisches Element oder setzen ein graphisches Element in dem Akkumulator zusammen, speichern die Inhalte des Akkumulators in den Renderstapelspeicher ein oder setzen ein aus dem Stapelspeicher entnommenes Element von dem Stapelspeicher in dem Akkumulator zusammen.
Selbstverständlich ist dann, wenn ein gerichtetes azyklisches Diagramm erlaubt ist, der Renderstapelspeicher selbst unzureichend, und es wird zusätzlicher temporärer Speicherplatz zur Speicherung gemeinsamer Unterausdrücke benötigt.
Für den hardwareunterstützten"Akkumulator"-Ansatz kann der "Anweisungssatz" realisiert werden, wie es in einer Tabelle 3 gezeigt ist:

Tabelle 3

clear acc ← null
load A acc ← A
over A acc ← A over acc
rover A acc ← acc over A
in A acc ← A in acc
rin A acc ← acc in A
atop A acc ← A atop acc
ratop A acc ← acc atop A
xor A acc ← A xor acc
plusW A acc ← A plusW acc
plusC A acc ← A plusC acc
out A acc ← A out acc
rout A acc ← acc out A
cmap M acc ← M(acc)
push Kopie von Akkumulator in Renderstapelspeicher einspeichern.
clip A,n A wird auch als ein Abschneidepfad n verwendet.
pushclip n Abschneidepfad n in Abschneidestapelspeicher einspeichern.
popclip Einen Abschneidepfad aus Abschneidestapelspeicher entnehmen.
In der Tabelle 3 steht das Wort "acc" für den Akkumulator, und M ist eine gewünschte Farbtransformationsfunktion.
Die Variable A kann ein beliebiges vordefiniertes graphisches Element sein, oder sie kann der Operand "aus dem Stapelspeicher entnehmen" bzw. "pop" sein, was es bedeutet, daß das derzeit an dem obersten Ende des Stapelspeichers befindliche graphische Element aus dem Stapelspeicher entnommen und als der Operand der Anweisung verwendet wird.
Allen vorstehenden Anweisungen wird eine Bounding-Box zugewiesen, in der sie arbeiten.
Die Entsprechung zwischen einem für Hardware entworfenen, akkumulationsbasierten Ansatz und einem für eine Softwarerealisierung entworfenen; stapelspeicherbasierten Ansatz stellt sich dar wie folgt:
1. Anweisungen "clear" und "load" folgen einander, sofern die Anweisung "clear" nicht herausoptimiert ist. Sie entsprechen einem Einspeichern eines Operanden in den Stapelspeicher, der durch einen Bereich der Opazität null umgeben ist. Die Anweisung "clear" kann daher für sich allein gesendet werden, wenn anschließend nichts zu laden ist.
2. Die Anweisung "push" kann übersprungen werden.
3. Ein Operand von "pop" für eine Anweisung wie beispielsweise "over" bedeutet es, daß die obersten zwei Elemente des Stapelspeichers miteinander zusammengesetzt werden sollen, wobei das sich ergebende zusammengesetzte Element in dem Stapelspeicher gelassen wird.
4. Ein Operand "A", der ein graphisches Element ist, bedeutet es, daß das graphische Element A in den Stapelspeicher eingespeichert wird, woraufhin die zwei obersten Elemente des Stapelspeichers zusammengesetzt werden, wobei das Ergebnis an dem obersten Ende des Stapelspeichers gelassen wird.
Wenn ein Ausdruckssyntaxbaum in eine Renderliste zu wandeln ist, werden mehrere Durchläufe durch den Ausdruckssyntaxbaum ausgeführt. Diese Durchläufe führen die nachstehenden Aufgaben aus:
1. Primitive, die nicht durch die Renderhardware (oder Rendersoftware) unterstützt werden, zu Ausdrücken erweitern.
2. Unäre Optimierungen ausführen.
3. Die Bounding-Box der Blattknoten und der inneren Knoten des Ausdrucksbaums bestimmen.
4. Bounding-Box-Minimierungen ausführen.
5. Abschneidepfade erkennen und abgeschnittene Knoten etikettieren.
6. Optimierungen ausführen.
7. Den Ausdrucksbaum in eine entsprechende Renderanweisungssatzliste wandeln.
8. Eine sortierte Renderanweisungsliste aufbauen.
Die vorstehenden Durchläufe sind nachstehend unter getrennten Überschriften genauer dargelegt.

1. Primitive erweitern, die nicht durch die Renderhardware (oder Rendersoftware) unterstützt werden.

Verschiedene Primitivfunktionen können möglicherweise nicht durch die Hardware- oder Softwarerealisierung unterstützt werden. Ein Beispiel könnte darin bestehen, daß zwei unabhängige Bildelementströme zur Bildung eines einzelnen Operanden kombiniert werden müssen. Falls z. B. sowohl die Farbe als auch die Opazität einen Teil eines Bilds bilden, aber von zwei verschiedenen Variablen kommen, kann die Hardware nicht dazu in der Lage sein, einen Bildelementstrom, der die Farbe bereitstellt, zu der gleichen Zeit wie einen zweiten Bildelementstrom, der die Opazität bereitstellt, zu kombinieren. In diesen Fällen stellt sich das Primitiv, das diese Situation darstellt, wie folgt dar:
"Farbe = A, Opazität = B"
Dieses Primitiv kann ersetzt werden durch den Ausdruck:
"(Farbe = A, Opazität = vollständig opak) in (Farbe = null, Opazität = B)"
an diesem Punkt.
7. Den Ausdrucksbaum in eine entsprechende Renderanweisungssatzliste wandeln.
Der Prozeß für die Wandlung des Ausdrucksbaums in eine entsprechende Renderliste (Durchlauf 7) kann durch den nachstehenden Pseudo-Code beschrieben werden:
procedure do_node(n)
if n ein Blatt ist then
erzeuge Anweisung "load n.operand"
else if n ein unärer Operator ist then begin
do_node(n.operand)
erzeuge Anweisung "cmap n.map"
end else begin
do_node(n.right)
if n.left ein Blatt ist then
erzeuge Anweisung "n.operation n.left.operand"
else begin
erzeuge Anweisung "push n.left.bounding-box"
erzeuge Anweisung "clear n.left.bounding-box"
do_node (n.left)
erzeuge Anweisung "reverse(n.operation)pop"
end
end
Bei dem vorstehenden Übersetzungsprozeß erzeugt die Funktion "reverse(n.operation)" die zu ihrem Parameter "n.operation" umgekehrte Operation. Es wird z. B. "rover" statt "over" erzeugt, und "over" wird statt "rover" erzeugt. Formeller ist bei einem gegebenen Operator "op" die mit "revop" bezeichnete Umkehrung des Operators der Operator derart, daß A op B = B revop A.
Der vorstehende Übersetzungsprozeß wird eingeleitet, indem der Wurzelknoten an eine Prozedur übergeben wird, die zuerst die Anweisung "clear root.bounding-box" ausgibt und daraufhin einen Aufruf von do_node(Wurzel) mit dem Wurzelknoten als Argument ausführt.
Als eine weitere Realisierungsoptimierung kann ein "Abschneidestapelspeicher" ("clipping stack") von Formen, auf die abgeschnitten wird, verwendet werden. Die Zusammensetzung eines graphischen Elements, das nicht ein Zwischenergebnis in dem Renderstapelspeicher ist, wird auf den Schnitt aller Abschneideformen in dem Abschneidestapelspeicher abgeschnitten. Dies erhöht die Effizienz der Renderoperationen. Immer wenn eine Anweisung für ein graphisches Element erzeugt wird, z. B. "load n.operand" oder "n.operation n.left-operand", sollte sie daher durch Anweisungen "push clip" und/oder "pop clip" fortgesetzt werden, die zum Versetzen des Abschneidestapelspeichers in einen Zustand entsprechend dem, auf den der Operand abgeschnitten werden muß, benötigt werden.

3. & 4. Bounding-Boxen bestimmen und Boundin -Box- Minimierung ausführen.

Bei der vorstehenden Erläuterung ist es angenommen, daß jedes graphische Element von theoretisch unendlicher Ausdehnung ist. Offensichtlich würde die Zusammensetzung von zwei graphischen Elementen von unendlicher Ausdehnung eine übermäßig große, falls nicht unendliche Menge von Zeit benötigen. Die Technik der Verwendung von Bounding-Boxen wird zur deutlichen Verringerung der Anzahl von Bildelementen, die an jeder Zusammensetzungsoperation beteiligt sind, verwendet. Der Prozeß der Bounding-Box- Minimierung ist ferner dazu entworfen, den kleinsten Bereichsabschnitt jedes graphischen Elements zu finden, der zur Bildung des endgültigen Bilds benötigt wird. Die Bounding-Box-Minimierung erstreckt sich darauf, den kleinsten Bereich jedes inneren Knotens des Ausdruckssyntaxbaums zu finden, um die Anzahl von zusammenzusetzenden Bildelementen weiter zu minimieren. Ferner erkennt die Bounding-Box-Minimierung die Blätter oder ganzen Unterbäume des Ausdruckssyntaxbaums, die nicht zu dem endgültigen Bild beitragen. Der Prozeß des Entfernens von Komponenten der durch den Ausdrucksbaum dargestellten Bildbeschreibung, bei dem die Komponenten vollständig herausgeschnitten werden, wird "culling" genannt. Das Ergebnis des Prozesses der Bounding-Box- Minimierung besteht darin, jedem Knoten eine "Bounding-Box" zuzuweisen, die der Renderer bei der Erzeugung des dem Knoten entsprechenden Bilds ganz füllen muß. Umgekehrt muß der Renderer bei der Erzeugung des Bilds nie außerhalb der Bounding-Box zeichnen, da die Bounding-Box der einzige Bereich ist, der in dem Renderstapelspeicher gespeichert und aus ihm wiederhergestellt wird.
Nachstehend auf Fig. 15 bis 18 Bezug nehmend ist ein einfaches Beispiel für den Prozeß der Box-Minimierung erläutert. Fig. 15 veranschaulicht ein Bild, das z. B. aus den nachstehenden Angaben erzeugt werden kann:

Tabelle 4

Seite = Text("T"); (6)
Seite = Text("E"); (7)
Seite = Text("X"); (8)
Seite = Text("T"); (9)
Seite = Bild in Seite; (10)
B = Box out Kreis; (11)
Seite = Seite over B; (12)
Ein Ausdrucksbaum für diese Folge von Angaben ist in Fig. 16 veranschaulicht.
Der Prozeß der Bounding-Box-Minimierung findet über zwei Durchläufe statt. Der erste Durchlauf ist ein Tiefe-zuerst- Postorder-Traversieren bzw. depth-first-postorder- Traversieren des Ausdrucksbaums. In dem ersten Durchlauf wird die "natürliche" Bounding-Box jedes Knotens bestimmt. Für Blätter ist dies die Bounding-Box des graphischen Elements. Für innere Knoten werden die Bounding-Boxen des linken und rechten Unterbaums in einer von der Zusammensetzungsoperation des derzeitigen Knotens abhängigen Art und Weise kombiniert. Die Kombination stellt sich dar wie in einer Tabelle 5 dargelegt.

Tabelle 5: Kombination von Bounding-Boxen

Operator Bounding-Box von A Operator B
over Bounding-Box von beiden A & B
rover
xor
plusW
plusC
in Schnitt der Bounding-Boxen von A und B
rin
out Bounding-Box von A
ratop
rout Bounding-Box von B
atop
Nachstehend auf Fig. 17 Bezug nehmend ist ein Beispiel für diesen Prozeß in Bezug auf die vorstehenden Angaben und den Ausdrucksbaum gemäß Fig. 16 gezeigt. Der erste Abschnitt des in den vorstehenden Angaben zu rendernden Bilds ist das dem Buchstaben T 20 entsprechende graphische Element. Dieses Rendern tritt auf einer Seite 21 auf und tritt nur in einem vordefinierten Raum oder einer "Bounding-Box" 22 auf, die der einzige Abschnitt des abtastgewandelten Abschnitts von T ist, der auf der Seite 21 aufzuzeichnen ist. Die nächste Angabe 7 kombiniert das Bild der derzeitigen Seite mit dem dem Buchstaben E 24 entsprechenden graphischen Element. Wieder weist dieser Buchstabe selbst eine vorbestimmte Bounding-Box 25 auf. Die zwei Buchstaben E und T werden unter Verwendung des Operators over 26 kombiniert. Daher ist die mit dem Knoten bei dem Operator over 26 gespeicherte Bounding-Box 27 eine Kombination der zwei Bounding-Boxen 22, 25. Während die Routine der Bounding-Box-Minimierung ein depth-first-postorder-Traversieren des Ausdrucksbaums ausführt, werden die Nachfahrenknoten eines gegebenen Knotens besucht, bevor ein derzeitiger Knoten besucht wird, und daher besucht die Routine zuerst alle Blattknoten. Für jeden der Blattknoten 28-32 wird wie gezeigt zuerst die Bounding-Box des graphischen Elements berechnet, das zu rendern ist. Im Anschluß an die Berechnung der Bounding-Boxen der Blattknoten werden die Bounding-Boxen von inneren Knoten berechnet.
Nach der Berechnung der Bounding-Box 27 des inneren Knotens 26 können die Bounding-Boxen 27-28 wieder unter Verwendung des Operators over kombiniert werden 34. Ähnlich ist eine Bounding-Box 35 die Kombination von Bounding-Boxen 29 und 34 unter Verwendung des Operators over 37.
Wie aus Fig. 4 ersichtlich ist dann, wenn die zwei graphischen Objekte A und B unter Verwendung des Operators "over" kombiniert werden, das sich ergebende Bild die Kombination von A und B, wobei A Vorrang vor B hat. Daher muß sich die Bounding-Box über die kombinierten Bereiche von A und B erstrecken. Demgegenüber ist die Kombination von A und B unter Verwendung des Operators "in" lediglich für die Abschnitte eines Bilds definiert, in denen A und B überlappen, und folglich ist die Bounding-Box für den kombinierten Bereich der Schnitt der zwei Bounding-Boxen für A und B.
Bei einem Knoten 39 werden die zwei Bounding-Boxen 30, 35 unter Verwendung des Operators "in" kombiniert, und so ist die sich ergebende Bounding-Box 40 der Schnitt der zwei Bereiche 30 und 35.
Bei einem Knoten 41 werden die zwei Bounding-Boxen 31, 32 unter Verwendung des Operators out kombiniert. Aus Fig. 4 ist es ersichtlich, daß die Bounding-Box 42 des Knotens 41 die gleiche wie die Bounding-Box 32 ist. Schließlich werden die Bounding-Boxen 40-42 unter Verwendung des Operators over bei einem Knoten 43 kombiniert. Die entsprechende Bounding-Box 44 bei dem Knoten 43 ist die Vereinigung der zwei Bounding-Boxen 40-42. Dies schließt den ersten Durchlauf der Bounding-Box-Bestimmung ab. Es ist ersichtlich, daß der Bounding-Box-Prozeß ein Bestimmen einer kombinierten Bounding-Box von zwei graphischen Elementen umfaßt, wobei die Größe der kombinierten Bounding-Box nach der Verwendung der Operatoren wie in Fig. 4 gezeigt durch den kombinierten sich ergebenden Bereich bestimmt wird.
Die zweite Stufe oder der zweite Durchlauf der Bounding- Box-Minimierung umfaßt ein Tiefe-zuerst-Preorder- Traversieren bzw. depth-first-preorder-Traversieren des Syntaxausdrucksbaums. In dem zweiten Durchlauf wird die Bounding-Box der Nachfahren jedes inneren Knotens durch die Bounding-Box des Elternteils bzw. Vorgängers geschnitten. Dieser Prozeß wird rekursiv ausgeführt, so daß die neue Bounding-Box eines Nachfolgers zum Schneiden oder Minimieren der Bounding-Boxen seiner Nachfahren verwendet wird. Nachstehend auf Fig. 18 Bezug nehmend ist nachstehend ein Beispiel für diesen Prozeß erläutert. In Fig. 18 ist der gleiche Ausdruckssyntaxbaum wie gemäß Fig. 16 und Fig. 17 dargestellt. Ein Preorder-Traversieren umfaßt ein Besuchen des derzeitigen Knotens zuerst und daraufhin seines linken und rechten Nachfolgers. Daher wird bei einem Beginn bei dem Knoten 43 die Bounding-Box 44 mit der Bounding-Box 40 bei dem Knoten 39 geschnitten, und es tritt keine Änderung auf. Die Bounding-Box 44 wird auch mit der Bounding-Box 42 geschnitten, und es tritt wieder keine Änderung auf. Die Bounding-Box 40 wird daraufhin mit der bei dem Blattknoten 45 gespeicherten Bounding-Box 30 geschnitten. Das Ergebnis dieses Schnittprozesses ist die Bounding-Box 47.
Daher ist der einzige Abschnitt des Bilds oder graphischen Elements, der bei dem endgültigen Bild benötigt wird, der durch die Bounding-Box 47 definierte Abschnitt statt der alten Bounding-Box 30. Dies stellt eine wesentliche Ersparnis bei der Zusammensetzungszeit dar, da der Abschnitt des Bilds 47 alles ist, was bei Zusammensetzungsoperationen verwendet werden muß. Ähnlich wird bei dem Knoten 37 die Bounding-Box 40 mit der Bounding-Box 35 (Fig. 17) kombiniert, was zu einer Bounding-Box 48 mit verringerter Größe führt, was wieder zu wesentlichen Ersparnissen führt. Die Bounding-Box 48 wird daraufhin mit der Bounding-Box 29 (Fig. 17) bei einem Knoten 50 geschnitten. Der Schnitt der Bounding-Box- Bereiche 48, 29 ist ein Null-Bereich, was bedeutet, daß der Knoten 50 keinen Teil des endgültigen Bilds bildet. Daher kann dieser Knoten (und seine Nachfolger, falls vorhanden) aus dem gesamten Ausdruckssyntaxbaum gelöscht werden, wobei der sich ergebende Baum eine vereinfachte Form annimmt.
Die Bounding-Box 48 wird daraufhin mit der Bounding-Box 34 (Fig. 17) bei dem Knoten 36 geschnitten, was eine Bounding- Box 51 erzeugt, die wieder von verringerter Größe ist.
Die Bounding-Box 42 wird mit der Bounding-Box 32 (Fig. 17) bei einem Knoten 52 kombiniert, und es findet keine Verkleinerung statt. Die Bounding-Box 42 wird daraufhin mit der Bounding-Box 31 (Fig. 17) bei einem Knoten 53 geschnitten, was verglichen mit der vorherigen Bounding-Box 31 zu einer Bounding-Box 54 mit verringerter Größe führt.
Dieser Prozeß wird für jeden Knoten des Ausdruckssyntaxbaums ausgeführt, was hoffentlich zu wesentlichen Verkleinerungen bei den Bereichen führt, die gerendert werden müssen, um einen Teil des endgültigen Bilds zu bilden. Zusätzlich können dort, wo die Bounding- Box auf einen Null-Bereich verkleinert wird, ganze Unterbäume gelöscht werden, da diese Abschnitte des Ausdruckssyntaxbaums keinen Teil des endgültigen Bilds bilden.
Eine weitere Optimierung, die zur weiteren Verringerung der Größe von Bounding-Boxen verwendet werden kann, besteht darin, es zu erkennen, wenn einer der Operanden sich unter einem opaken Objekt befindet. Wenn z. B. der Operand ein Operand "over" ist und die Bounding-Box des rechten Operanden vollständig oder teilweise durch die Bounding-Box des linken opaken Operanden verdeckt wird, dann kann die Bounding-Box des rechten Operanden verkleinert oder beseitigt werden. In Fig. 30 sind z. B. zwei Objekte A 100 und B 101 gezeigt, die jeweils eine Bounding-Box 102 bzw. 103 aufweisen. In Fig. 31 ist die Operation A over B gezeigt, bei der das Objekt B teilweise durch die opaken Abschnitte des Objekts A verdeckt wird. Da ein wesentlicher Abschnitt des Objekts B hinter dem opaken Abschnitt des Objekts A versteckt ist, kann seine entsprechende Bounding- Box um den Teil verkleinert werden, der vollständig durch das Objekt A abgedeckt wird. Dies ist in Fig. 32 graphisch gezeigt, wobei eine Seite 105 der Bounding-Box für das Objekt B von 105 auf 106 verkleinert worden ist.
Eine einfache Form der Realisierung dieses Prozesses besteht darin, jeden Blattknoten des Ausdrucksbaums hinsichtlich graphischer Elemente A zu überprüfen, die opak sind und Ihre Bounding-Box vollständig füllen. In diesem Fall kann die Bounding-Box von B abhängig davon, ob sie durch die von A gänzlich verdeckt wird, verkleinert oder vielleicht beseitigt werden.

5. Erkennung von Abschneidepfaden und Etikettierung von abgeschnittenen Knoten.

Wie aus Fig. 4 ersichtlich ist dann, wenn eine Operation "in" oder "out" mit einem vollständig opaken rechten Operanden ausgeführt wird, der Effekt der gleiche, als ob der linke Operand auf die Grenzen des rechten Operanden abgeschnitten worden wäre. Mit der Operation "in" besteht der Effekt darin, lediglich die Teile des linken Operanden zu zeigen, die innerhalb des rechten Operanden liegen, und mit dem Operanden "out" besteht der Effekt darin, lediglich die Pfade des linken Operanden zu zeigen, die außerhalb des rechten Operanden liegen. Wenn die Grenzen des rechten Operanden bekannt sind, dann können diese Operationen "in" und "out" mit einem Abschneiden statt mit einem Zusammensetzen ausgeführt werden.
Ein einfaches Beispiel für diesen Prozeß ist nachstehend unter Bezugnahme auf Fig. 19-22 veranschaulicht. Nachstehend auf Fig. 19 Bezug nehmend ist die auszuführende gewünschte Operation "Quadrat in Kreis", wobei "Quadrat" das graphische Element 60 darstellt und "Kreis" das graphische Element 61 darstellt:
Das normale Zusammensetzungsverfahren zur Realisierung dieser Operation ist in Fig. 20 gezeigt, wobei das dem Kreis 61 entsprechende graphische Element geladen und in der Bildebene 62 zusammengesetzt wird. Anschließend wird wie in Fig. 21 gezeigt das Bild 62 (Fig. 20) als eine Matte gegen das quadratische graphische Element 60 verwendet, um einen Kreis 63 mit Farbdateninformationen von dem graphischen Element 60 zu erzeugen.
In Fig. 22 ist ein effizienteres Verfahren zur Ausführung der Operation gemäß Fig. 19 gezeigt. In diesem Fall wird das graphische Element 60 unmittelbar gegen die Ränder des graphischen Elements 61 abgeschnitten, um die endgültige Ausgabe 64 zu erzeugen.
Es ist nicht immer klar, ob das Zusammensetzen oder das Abschneiden das sowohl hinsichtlich der Computerzeitanforderungen als auch der Speicherplatzanforderungen effizientere zu verwendende Verfahren wäre. Die nachstehenden Beobachtungen sollten jedoch beachtet werden:
1. Wenn ein graphisches Element als der linke Operand einer Operation "in" verwendet wird, wobei ein opakes graphisches Element der rechte Operand ist, dann umfaßt das Abschneiden ein Auswählen der sichtbaren Teile des linken Operanden und lediglich ihr Zusammensetzen. Das Zusammensetzen umfaßt demgegenüber ein Speichern des derzeitigen Bilds, ein Rendern des ganzen graphischen Elements des rechten Operanden, ein Zusammensetzen des ganzen linken Operanden und schließlich ein Zurückzusammensetzen des gespeicherten Bilds.
2. Aus dem Abschneiden von Bildern können sich große Ersparnisse ergeben, da dies die Menge von Bildelementdaten, die zusammengesetzt werden müssen, deutlich verringern kann und auch die Menge von Bildelementdaten verringern kann, die vor dem Zusammensetzungsprozeß erzeugt wird.
3. Es können Zeiten vorhanden sein, in denen das Abschneideobjekt ziemlich kompliziert ist, so daß der Gewinn bei der verringerten Zusammensetzung den Berechnungszuschlag bei dem Schneiden des abzuschneidenden Objekts mit dem Abschneideobjekt nicht Wert ist. Dies ist wahrscheinlich der Fall, wenn das Abschneideobjekt aus kleinem Text oder sehr komplizierten Pfaden besteht.
Bei der Realisierung der vorstehenden Abschneideoptimierung bei einem beliebigen Ausdrucksbaum ist es zu beachten, daß ein Abschneiden, d. h. "in" oder "out" mit einem vollständig opaken rechten Operanden oder umgekehrt "rin" oder "rout" mit einem vollständig opaken linken Operanden über alle binären Zusammensetzungsoperatoren (d. h. die Operatoren mit zwei Argumenten) distributiv ist. Bei einem gegebenen vollständig opaken graphischen Element C gilt daher für alle binären Zusammensetzungsoperatoren op die nachstehende Beziehung:
(a op b) in c = (a in c) op (b in c)
Gleichung 1
Der Abschneideprozeß ist auch über alle unären Operatoren distributiv, sofern nicht unsichtbare Bereiche auf sichtbare Bereiche abgebildet werden. Dieser letztere Fall wird als selten angesehen und kann als ein Spezialfall behandelt werden.
Ein Beispiel für das Abschneiden ist unter Bezugnahme auf Fig. 23-24 erörtert. Fig. 23 veranschaulicht ein Beispiel für den Zusammensetzungsprozeß für einen Abschnitt eines Ausdrucksbaums 65. Dieser Abschnitt des Ausdrucksbaums 65 wird in die entsprechende Liste von Maschinenanweisungen 66 kompiliert. Die Liste 66 umfaßt das Einspeichern des derzeitigen Bilds in den Stapelspeicher (push), das Rendern des opaken Operanden auf der rechten Seite in den Akkumulator (load P), das Zusammensetzen des linken Operanden unter Verwendung des Operators "in" (in B) und das Zurückzusammensetzen des gespeicherten Bilds (rover Pop)
Fig. 24 veranschaulicht den Prozeß des Abschneidens statt des Zusammensetzens, wenn der rechte Operand ein opakes Objekt ist. In dieser Situation wird der Ausdrucksbaum 65 gemäß Fig. 23 zuerst verarbeitet, um alle Fälle zu lokalisieren, in denen ein graphisches Element unter Verwendung eines Operators "in" oder "out", z. B. 68 (Fig. 23), gegen ein opakes graphisches Element abgeschnitten wird. In jedem Fall wird dieses durch einen speziellen Knotenindikator 69 ersetzt, und die Grenzen des Abschneideobjekts werden in einer getrennten Abschneideliste 70 plaziert. Bei der Kompilierung des neuen Ausdrucksbaums 67 ergibt sich daraufhin die Codefolge 72. In dieser Codefolge ist das der als ein Element 1 in der Abschneideliste 70 gespeicherten Grenze von P entsprechende Abschneideobjekt vor jeder anderen Anweisung, die ein Abschneiden auf P umfaßt, als eine Anweisung "abschneiden" bzw. "clip" in der Renderliste plaziert (clip P,1). Unmittelbar vor irgendwelchen späteren Anweisungen wird das Element 1 der Abschneideliste, das der Grenze von P entspricht, in den Abschneidestapelspeicher eingespeichert (pushclip 1). B wird daraufhin über den Schnitt aller Grenzen in dem Abschneidestapelspeicher gerendert (over B), das Objekt an dem obersten Ende des Abschneidestapelspeichers wird daraufhin aus dem Stapelspeicher entnommen, und die Anweisungsfolge wird wie in Fig. 23 fortgesetzt.
Das nachstehende Schema der Realisierung ist daher möglich:
1. Der Arbeitssatz von Zeigern des Ausdrucksbaums wird nach Pfaden durchsucht, die in der vorstehenden Art und Weise gewandelt werden können. Wenn ein Pfad oder Objekt gefunden wird, wird er oder es aus dem Satz von Arbeitsbaumzeigern entfernt und in eine die Abschneideliste genannte regelmäßige Anordnung gestellt. Ein Index in diese regelmäßige Anordnung (eine Abschneide-ID) wird zusätzlich dazu in dem derzeitigen Knoten aufgezeichnet, daß es aufgezeichnet wird, ob die Optimierung ein Ergebnis einer Operation "iri" oder "out" war.
2. Bei einem rekursiven Durchlaufen des Ausdrucksbaums nach unten ist es notwendig, die Abschneide-ID jedes graphischen Elements im Auge zu behalten, das in ein Abschneideobjekt in der Abschneideliste gewandelt worden ist, so daß Blattknoten von nachfolgenden Abschnitten des Ausdrucksbaums, die gemäß der Abschneide-ID ein Abschneiden erfordern, markiert werden können. Da jeder anfänglich abgeschnittene Unterbaum weitere Abschnitte umfassen kann, die zur Wandlung in Abschneideumrisse geeignet sind, ist es notwendig, einen Stapelspeicher von Abschneide-ID zu unterhalten. Wann immer ein graphisches Element gefunden wird, das in einen Abschneideumriß zu verwandeln ist, kann seine Abschneide-ID in den Stapelspeicher eingespeichert werden, der abgeschnittene Unterbaum kann daraufhin traversiert werden, und bei der Rückkehr kann die Abschneide-ID an dem obersten Ende des Stapelspeichers aus dem Stapelspeicher entnommen werden. Wann immer bei dem Traversieren ein Blattknoten angetroffen wird, wird er zu dieser Zeit mit allen derzeit in dem Stapelspeicher befindlichen Abschneide-ID markiert.
3. Wenn die Renderliste erzeugt wird, werden die für die Erzeugung jedes graphischen Elements, das in ein Abschneideelement gewandelt und in der Abschneideliste gespeichert worden ist, benötigten Anweisungen "clip" erzeugt, bevor das Element verwendet wird (wie beispielsweise bei dem Beginn des Programms).
4. Der "clip stack" bzw. "Abschneidestapelspeicher" zu der Renderzeit kann durch Anweisungen "push clip" und "pop clip" manipuliert werden, die die verschiedenen Zusammensetzungsanweisungen umgeben. Wenn ein graphisches Objekt zusammenzusetzen ist, wird es auf alle zu dieser Zeit in dem Abschneidestapelspeicher befindlichen Abschneideobjekte abgeschnitten. Somit ist es bei der Erzeugung der Renderliste von Anweisungen notwendig, den Zustand im Auge zu behalten, den der Abschneidestapelspeicher aufweisen wird, wenn ein graphisches Element zusammengesetzt wird. Falls der Zustand des Abschneidestapelspeichers nicht wie in dem erforderlichen Zustand ist. Für unäre Operatoren, die unsichtbare Bildelemente in sichtbare Bildelemente wandeln, ist bei ihrer Verwendung ein zusätzliches Abschneiden erforderlich. D. h., es ist notwendig, den Operator lediglich auf sichtbare Abschnitte eines graphischen Elements anzuwenden und den Zustand von abgeschnittenen Bereichen zu belassen, die als unsichtbar gelten.
Selbstverständlich können graphische Elemente verursacht durch ihre minimierten Bounding-Boxen ein weiteres Abschneiden zusätzlich zu dem vorstehenden Abschneideprozeß erfordern.

2. Unäre Optimierungen ausführen.

Der Anweisungssatz stellt eine Anweisung (cmap M) zur Änderung der Farben von bestimmten graphischen Elementen gemäß der durch M definierten Abbildung bereit.
Gelegentlich können Farbtabellenoperationen, die in der Seitenbeschreibungssprache verfügbar sein können, auf der Ausdrucksbaumstufe statt während des Renderns ausgeführt werden. Falls es z. B. erforderlich ist, die Farbe des graphischen Elements unter Verwendung einer Farbtabelle zu ändern, kann es möglich sein, die Farbe des Elements zu ändern, bevor der Renderprozeß stattfindet, und so die Entfernung der Farbabbildungsoperation aus dem Ausdrucksbaum zu ermöglichen. Gelegentlich kann jedoch die Farbe eines graphischen Elements bei einer Farbtabellenoperation mit seinen Opazitätswerten oder α- Kanal-Werten interagieren. Die Farbtabellenoperation muß sorgfältig analysiert werden, um es zu bestimmen, ob sie auf der Ausdrucksbaumstufe angewendet werden kann oder nicht.
Zusätzlich kann jedes graphische Element vereinfacht werden, wenn seine Farbe berücksichtigt wird. Unter Bezugnahme auf Fig. 33 kann z. B. das allgemein durch 108 angegebene graphische Objekt einen Bereich 109 mit einer komplizierten Form von Farbmischung und einen zweiten Bereich 110 mit einer konstanten Farbmischung aufweisen. Der Prozeß der Bounding-Box-Optimierung wie vorstehend umrissen kann eine optimierte Bounding-Box 111 erzeugt haben, die eine Grenze aufweist, die nichts von dem Bereich 109 umfaßt. Somit kann die Farbe des Objekts 108 derart geändert werden, daß sie von einer zu der des Bereichs 110 äquivalenten konstanten Farbe ist, wenn der entsprechende Ausdrucksbaum ausgewertet wird.

6. Optimierung

Verschiedene Formen von Optimierung sind bei dem Ausdrucksbaum möglich. Zuerst können wie vorher angeführt die Abschnitte des Ausdrucksbaums, deren Bounding-Boxen zu null minimiert worden sind, aus dem Ausdrucksbaum gelöscht werden.
Die algebraischen Eigenschaften von Zusammensetzungsoperatoren können verwendet werden, um den Ausdrucksbaum neu anzuordnen, so daß effizientere Operationen für aufwendigere Operationen eingesetzt werden, wo immer es möglich ist. Diese algebraischen Eigenschaften sind Identitäten, die die Assoziativität, die Kommutativität und die Umkehrung der verschiedenen Operatoren umfassen. Der Optimierungsprozeß umfaßt ein Traversieren des Baums in einer Preorder-Art, und der Optimierer testet es bei jedem Knoten, ob jede Regel eines Satzes von aus den algebraischen Eigenschaften abgeleiteten Regeln zu dem derzeitigen Knoten paßt. Bei der Bestimmung, welche Regeln Anwendung finden können, wird eine Schätzung der wahrscheinlichen Verbesserung bei dem Aufwand des Renderns des Ausdruckbaums durch seine Modifikation gemäß der algebraischen Eigenschaft ausgebildet. Der Aufwand eines gegebenen Knotens kann als eine lineare Kombination der Höhe (h) und des Bereichs (h · w) der Bounding-Box des linken Unterbaums geschätzt werden. Wie es nachstehend klarer wird, können die Assoziativitätseigenschaften dazu verwendet werden, den Ausdrucksbaum nach rechts schiefzulegen, um die während des Renderprozesses erforderliche Stapelspeichertiefe deutlich zu verringern. Ein Austauschen der Unterbäume eines Knotens durch ein Anwenden eines kommutativen oder umgekehrten Operators sollte daraufhin nur angewendet werden, falls der Aufwand hinsichtlich des Bereichs, der zusammengesetzt werden muß, gesenkt wird. Dies kann zu einer erhöhten Stapelspeichertiefe, aber einer entsprechenden Abnahme der Ausführungszeit führen.
Jeder Knoten des Ausdruckssyntaxbaums speichert die Anzahl von Abtastzeilen h und den Bereich hw der Bounding-Box in Bildelementen. Daher müssen zur Bestimmung des Aufwands einer gemeinsamen Operation wie beispielsweise "A over B" die nachstehenden Faktoren geschätzt werden:
- Clover ist der Aufwand pro Abtastzeile für die Ausführung eines "over" bei einem einfachen graphischen Element.
- Clover ist der Aufwand pro Bildelement für die Ausführung eines "over" bei einem einfachen graphischen Element.
- Clover ist der Aufwand pro Abtastzeile für die Ausführung eines "over" bei einem komplizierten graphischen Element, das aus der Kombination von vielen einfachen graphischen Elementen besteht.
- Clover ist der Aufwand pro Abtastzeile für die Ausführung eines "over" bei einem komplizierten graphischen Element.
- h ist die Anzahl von Abtastzeilen in der Grenze von A.
- hw ist die Anzahl von Bildelementen in den Grenzen von A.
Die gesamten Kostenstellen sich daher dar wie folgt:
if das graphische Element einfach ist then
Aufwand = Clover h + Clover hw
else das graphische Element kompliziert ist
Aufwand = Clover h + Clover hw
Gleichung 2
Die Assoziativitätseigenschaft kann dazu verwendet Werden, den Ausdrucksbaum schiefzulegen. Ein schiefgelegter Ausdrucksbaum wird meistens zu einem entsprechenden Satz von Renderanweisungen führen, die weniger Zeit und Speicher zur Ausführung beanspruchen. Unter Bezugnahme auf Fig. 25 ist ein Beispiel für ein Schieflegen eines Abschnitts 75 eines Ausdrucksbaums nach rechts zur Erzeugung eines entsprechenden nach rechts schiefgelegten Abschnitts 76 gezeigt. Eine Formel zur Berechnung, ob die in Fig. 25 dargestellte Operation ausgeführt werden sollte, stellt sich dar wie folgt:
fover (A) + fover (Y) > fover (A) + fover (B)
fover (Y) > fover (B),
Gleichung 3
wobei fover(Z) der Aufwand der Ausführung einer "over"- Zusammensetzung des graphischen Elements Z ist.
Da die Bounding-Box von B immer gleich oder kleiner als Y in dem Abschnitt 75 sein wird und ein Zusammensetzen eines komplizierten graphischen Elements meistens schwieriger ist als ein Zusammensetzen eines einfachen graphischen Elements, stellt diese Assoziativitätsoperation beinahe immer einen schnelleren oder gleich schnellen Syntaxausdrucksbaum zum Rendern bereit. Der Baum kann einfach geändert werden, indem die Zeiger von 75 zu 76 geändert werden.
In Bezug auf die Operatoren, die kommutativ sind, kann es vorteilhaft sein, einige der Operanden eines kommutativen Operators auszuwechseln. In Figur. 26 werden z. B. die Operanden des Operators "xor" bildlich ausgewechselt. Die Entscheidung zum Auswechseln hängt von dem Aufwand des linken Baums und dem Aufwand des rechten Baums ab. Falls
fxor (A) > fxor (B),
Gleichung 4
werden daher die Operanden ausgetauscht. Dies wird meistens von der Speichergröße abhängen, die zum Rendern von zwei Bereichen A und B erforderlich ist, und kann einfach realisiert werden, indem wieder wie in Fig. 26 gezeigt die Zeiger geändert werden.
Gelegentlich kann es nützlich sein, einige Operatoren gegen ihre Inversen auszutauschen. Fig. 27 veranschaulicht z. B. den Prozeß des Invertierens des Operators "in" zu seiner Inversen "rin" mit dem entsprechenden Austauschen von Zeigern. Wieder wird es die Berechnung des vorgeschlagenen Aufwands der zwei Verfahren bestimmen, ob ein Austausch ausgeführt werden sollte. Eine Anzahl von anderen Optimierungen ist gemäß der nachstehenden Folge von Transformationen möglich:

Tabelle 6

(a over b) over c → a over (b over c)
→ a over (c rover b)
→ c rover (a over b)
→ c rover (b rover a)
(a over b) rover c → c over (a over b)
→ c over (b rover a)
→ b rover (c over a)
→ b rover (a rover c)
(a rover b) over c → b over (a over c)
→ b over (c rover a)
→ c rover (b over a)
→ c rover (a rover b)
(a rover b)rover c → c over (b over a)
→ c over (a rover b)
→ a rover (c over b)
→ a rover (b rover c)
(a in b) in c → a in (b in c)
→a in (c rin b)
→c rin (a in b)
→c rin (b rin a)
(a in b) rin c → c in (a in b)
→c in (b rin a)
→b rin (c in a)
→b rin (a rin c)
(a rin b) in c → b in (a in c)
→ b in (c rin a)
→ c rin (b in a)
→ c rin (a rin b)
(a rin b) rin c → c in (b in a)
→ c in (a rin b)
→ a rin (c in b)
→ a rin (b rin c)
(a plusC b) plusC c → a plusC (b plusC c)
→ a plusC (c plusC b)
→ b plusC (a plusC c)
→ b plusC (c plusC a)
→ c plusC (a plusC b)
→ c plusC (b plusC a)
(a plusW b) plusW c → a plusW (b plusW c)
→ a plusW (c plusW b)
→ b plusW (a plusW c)
→ b plusW (c plusW a)
→ c plusW (a plusW b)
→ c plusW (b plusW a)
a xor b → b xor a
a plusC b → b plusC a
a plusW b → b plusW a
A over b → b rover a
a rover b → b over a
a in b → b rin a
a rin b → b in a
a out b → b rout a
A rout b → b out a
A atop b → b ratop a
a ratop b → b atop a
Zusätzlich sind viele andere Transformationen vorhanden, die besonders dann angewendet werden können, wenn der beteiligte Unterbaum der rechte Operand eines Operators "in" oder "out" (oder äquivalent der linke Operand eines Operators "rin" oder "rout") ist.
Alle vorher angeführten Optimierungen und Änderungen bei dem Ausdrucksbaum können bei dem Arbeitssatz von Zeigern ausgeführt werden, so daß der Satz von Zeigern des Benutzers unverändert bleibt und folglich die Änderungen nicht erkannt werden, sollte eine Änderung des Ausdrucksbaums notwendig sein.
Sobald der Ausdrucksbaum optimiert worden ist, kann er daraufhin wie vorher umrissen (Schritt 7) zur Erzeugung der Renderlistenanweisungen verwendet werden.
Nachstehend auf Fig. 28, 29 Bezug nehmend ist nachstehend ein komplizierteres Beispiel für die Manipulation des Ausdrucksbaums offenbart. Ein Anfangsabschnitt des Ausdrucksbaums 80 ist in eine Folge von Zwischencodeanweisungen zu wandeln. Ein erstes Verfahren zur Wandlung besteht darin, lediglich den Abschnitt des Ausdrucksbaums 80 in Fig. 28 zu optimieren, um einen entsprechenden optimierten Abschnitt des Ausdrucksbaums 81 zu bilden. Die bei dem Baum ausgeführten Optimierungen umfassen das Ändern des Operanden 83 von "in" zu "rin" 84. Die Änderung dieses Operators weist eine daraus folgende Permutation seiner Operanden auf und tritt als ein Ergebnis dessen auf, daß der Operand P wesentlich kleiner als der Unterbaumoperand ist, dessen Wurzel der Operator "over" 86 ist. Der optimierte Ausdruckssyntaxbaum 81 wird daraufhin in Zwischencodeanweisungen 87 gewandelt. Das Grundprinzip hinter dieser Optimierung besteht darin, daß der Baum 80 zwei Einspeicher- und Entnahmevorgänge in bzw. aus dem Stapelspeicher erfordern würde, wohingegen der Baum 81 lediglich einen erfordert. Es ist somit wahrscheinlich, daß der einfachere Satz von Anweisungen, der sich aus dem Baum 81 ergibt, schneller auszuführen ist und weniger Speicher erfordert.
Fig. 29 zeigt alternative Formen des Abschnitts des Ausdrucksbaums 80, wenn ein Abschneiden verwendet wird. Es wird angenommen, daß das graphische Element P 85 ein opakes Objekt ist, und folglich wird das durch den Operator "over" 86 erzeugte graphische Element unter Verwendung eines Operators "in" 83 mit dem opaken graphischen Element 85 kombiniert. Wie mit Bezug auf Fig. 19-22 umrissen kann ein Abschneiden gegen das opake Objekt P 85 statt des Operators "in" verwendet werden. Daher wird der Umriß 89 von P zusammen mit dem in Verbindung mit dem Operanden 85 verwendeten Operator 83 in einer Abschneideliste gespeichert.
Da die Abschneideoperation über alle anderen binären Zusammensetzungsoperatoren distributiv ist (siehe Gleichung 1) kann ein Abschneiden auf P 85 über die Operatoren 86, 91 verteilt werden, was dazu führt, daß jeder der Blattknoten 92-94 zum Abschneiden gegen den in der Abschneideliste gespeicherten Umriß 89 markiert wird.
Der sich ergebende Ausdrucksbaum 96 kann daraufhin zur Bildung eines optimierten Ausdrucksbaums 97 optimiert werden. Der optimierte Ausdrucksbaum 97 wird durch eine wiederholte Anwendung der assoziativen Regel für den Operator "over" (wie in der Tabelle 4 dargelegt), die die Form (A over B) over C = A over (B over C) aufweist, aus dem Ausdrucksbaum 96 gebildet.
Der optimierte Ausdrucksbaum wird daraufhin verwendet, um daraufhin Zwischenanweisungen 98 zu erzeugen. Durch einen Vergleich der Liste von Anweisungen 87 (Fig. 28) mit der Liste von Anweisungen 98 (Fig. 29) ist es ersichtlich, daß die Liste 87 eine Anweisung "in den Stapelspeicher einspeichern" bzw. "push" zum Einspeichern der derzeitigen Inhalte des Akkumulators in den Stapelspeicher zusätzlich zu dem Laden oder Zusammensetzen der Gesamtheit von B&sub1;, B&sub2; und B&sub3;, bevor sie der Anweisung "rin" mit P als dem Operanden unterzogen werden, umfaßt. Das Ergebnis dieser Operation wird daraufhin mit dem obersten Ende des Stapelspeichers zusammengesetzt (durch die Anweisung "rover pop"). Bei der zweiten Folge von Anweisungen 98 wird die Abschneideliste anfänglich mit dem Umriß von P geladen, A wird daraufhin auf den derzeitigen Akkumulatorinhalten zusammengesetzt, wobei ein Einspeichern des Umrisses von P in den Abschneidestapelspeicher und das nachfolgende Zusammensetzen von B&sub1;, B&sub2; und B&sub3; über den Umriß von P, der sich an dem obersten Ende des Abschneidestapelspeichers befindet, folgen. Das oberste Ende des Abschneidestapelspeichers wird daraufhin aus dem Stapelspeicher entnommen (Anweisung "popclip"), bevor C daraufhin über den verbleibenden Inhalten des Akkumulators zusammengesetzt wird. Es ist wahrscheinlich, daß die Folge von Anweisungen 98 wesentlich effizienter als die Folge von Anweisungen 87 ist, wobei die Beschleunigungen durch die Verwendung eines Abschneidens statt eines Zusammensetzens und die Verwendung der assoziativen Operatoren erreicht werden.
Wie vorher angeführt kann die aus dem Ausdruckssyntaxbaum erzeugte Anweisungsfolge zur Ausführung auf einem softwarebasierten Gerät oder einem hardwarebasierten Gerät angepaßt werden. Nachstehend ist unter Bezugnahme auf Fig. 34 ein beispielhafter hardwarebasierter Ansatz offenbart. Nachstehend auf Fig. 34 Bezug nehmend ist eine beispielhafte Hardwarearchitektur 120 gezeigt, die dazu eingerichtet ist, Folgen von Anweisungen wie z. B. in der Tabelle 3 dargelegt auszuführen. Die Hardwarearchitektur 120 kann durch die Anpassung von
Standardcomputerarchitekturtechniken wie in Standardlehrbüchern wie z. B. in den Kapiteln 3 bis 8 des Texts "Computer Architecture - A Quantitative Approach" von John Hennessy und David Patterson, 1990, veröffentlich von Morgan Kaufmann Publishers Inc. dargelegt realisiert werden.
Die Hardwarearchitektur 120 ist dazu entworfen, unter der Steuerung eines externen Standardcomputersystems 125 zu arbeiten, das mittels einer Eingabe-/Ausgabeschnittstelle 123, die von einem Standardtyp wie beispielsweise PCI oder dergleichen sein kann, mit der Hardwarearchitektur 120 in Verbindung tritt.
Wie vorher vermerkt werden die Anweisungsfolgen normalerweise gemäß der Abtastzeilenreihenfolge sortiert, und es wird durch das externe Computersystem 125 eine aktive Liste für eine derzeitige Abtastzeile unterhalten. In der Hardwarearchitektur 120 werden Anweisungsfolgen für eine spezielle derzeit aktive Abtastzeile von dem externen Computersystem 125 über eine Eingabe-/Ausgabeschnittstelle 123 in einen Anweisungsspeicher 121 geladen, und die durch die Anweisungsfolge benötigten graphischen Elemente werden zusätzlich zu der Abschneideliste in einen Speicherungsspeicher 122 geladen. Der Steuerabschnitt 126 wird daraufhin aktiviert und beginnt ein Lesen von Anweisungen aus dem Anweisungsspeicher 121 und ein Ausführen von ihnen mittels eines mikroprogrammierten Speichers, der in dem Steuerabschnitt 126 gespeichert ist, wobei wieder Standardtechniken verwendet werden.
Ein Akkumulator 128 weist ausreichend Speicherplatz zur Speicherung der Farbinformationen und Opazitätsinformationen für eine ganze Abtastzeile auf. Ein Stapelspeicherplatz 130 weist ausreichend Platz zur Speicherung einer vorbestimmten maximalen Anzahl von Abtastzeilen auf, die die maximale Tiefe darstellen, bis zu der der Stapelspeicher bei jeder Zeile wächst.
Jedesmal, wenn durch den Steuerabschnitt 126 eine Anweisung "pushclip" in der Anweisungsfolge angetroffen wird, wird das in der Abschneideliste in dem Speicherungsspeicher 122 gespeicherte relevante Abschneideobjekt mit den derzeitigen Inhalten des obersten Endes eines Abschneidestapelspeichers 132 geschnitten und das Ergebnis als ein neues oberstes Element des Abschneidestapelspeichers 132 gespeichert. Wenn eine Anweisung "popclip" angetroffen wird, wird das derzeitige oberste Ende des Abschneidestapelspeichers 132 aus dem Stapelspeicher entnommen.
Für jede Zusammensetzungsanweisung steuert der Steuerabschnitt 126 die Operation einer Zusammensetzungseinrichtung 127, die die Zusammensetzungsoperationen gemäß der Tabelle 1 bei zwei Bildelementfarb- und -opazitätsströmen realisiert, wobei der erste Strom von einem Akkumulator 128 kommt und ein zweiter Strom von dem Stapelspeicherplatz 130 kommt (wenn erforderlich). Der Steuerabschnitt 126 bestimmt die Grenzen der Zusammensetzung der Bildelementströme aus dem derzeitigen obersten Element des Abschneidestapelspeichers 132. Die sich ergebende Farb- und Opazitätsausgabe der Zusammensetzungseinrichtung 127 wird zu dem Akkumulator 128 zurückgeführt 131.
Sobald die Anweisungsfolge abgeschlossen worden ist, benachrichtigt der Steuerabschnitt 126 das Computersystem 125, das die Ergebnisse für die derzeitige Abtastzeile aus dem Akkumulator 128 liest und das Ergebnis wie gewünscht entweder ausgibt oder speichert.
Das bevorzugte Ausführungsbeispiel wie zuvor beschrieben ist in einer derartigen Form dargestellt worden, daß die Klarheit und das Verständnis des Fachmanns auf dem Fachgebiet der Computergraphik, der Algorithmen, der Datenstrukturen, der Computerarchitektur und des Schreibens von Kompilierern maximiert werden. Selbstverständlich können viele weitere Optimierungen möglich sein. Die Verwendung einer Rekursion bei dem Traversieren des Baums kann z. B. unter Verwendung bestimmter bekannter Verfahren wie beispielsweise einer Endrekursion oder einem Unterhalten von Rückzeigern beseitigt werden.
Zusätzlich ist normalerweise in Standardprogrammiersprachen einschließlich Seitenbeschreibungssprachen ein breites Spektrum von Einrichtungen verfügbar. Dies Einrichtungen variieren normalerweise von Sprache zu Sprache, und so sind die tatsächlichen Einzelheiten einer speziellen Sprache nicht angenommen worden. Selbstverständlich ist ein Fachmann auf den vorstehenden Gebieten dazu in der Lage, das zuvor beschriebene Ausführungsbeispiel leicht in einer Seitenbeschreibungssprache zu realisieren.
Nachstehend auf Fig. 35 Bezug nehmend ist nachstehend der gesamte Prozeß der Kompilierung und Ausführung einer Folge von Programmiersprachenanweisungen erläutert. Zuerst werden in einem Schritt 200 die gewünschten Programmiersprachenanweisungen erzeugt. Diese Anweisungen können gemäß einer gültigen Syntaxbeschreibung für die Programmiersprache von Hand erzeugt werden, sie werden jedoch vorzugsweise unter Verwendung einer Seitenlayoutanwendung in der normalen Art und Weise erzeugt.
Sobald eine gültige Liste von Programmiersprachenanweisungen erhalten ist, kann wie bei einem Schritt 201 angegeben jede Anweisung durch das Computersystem 125 (Fig. 34) interpretiert werden, um einen entsprechenden Ausdrucksbaum wie zuvor z. B. mit Bezug auf Fig. 16 beschrieben aufzubauen. Die Knoten des Ausdrucksbaums können die relevanten Bounding-Box- Informationen eines bei dem Knoten zu verwendenden graphischen Elements umfassen. Der erzeugte Ausdrucksbaum hängt von den syntaktischen Konstruktionen der Sprache und der ausgeführten speziellen Folge von Anweisungen ab.
Der Ausdruckssyntaxbaum kann daraufhin in einem Schritt 202 durch das Computersystem 125 gemäß der vorher unter Bezugnahme auf die Ausführung von Durchläufen bei dem Ausdruckssyntaxbaum angeführten verschiedenen Optimierung optimiert werden. Diese Optimierungen können die unter Bezugnahme auf Fig. 17 und 18 beschriebenen Bounding-Box- Optimierungen, die mit Bezug auf Fig. 22 bis 24 beschriebenen Abschneideoptimierungen und die unter Bezugnahme auf Fig. 25 bis 27 beispielhaft beschriebenen Baumoptimierungen umfassen.
Als nächstes kann in einem Schritt 203 durch das Computersystem 125 eine Folge von Assemblersprachenanweisungen aus dem optimierten Ausdruckssyntaxbaum gemäß dem Schritt 202 erzeugt werden.
Diese Anweisungen umfassen die Renderanweisungssatzliste für die Ausführung durch die Hardwarearchitektur 120.
Sobald die Rerideranweisungssatzliste erzeugt worden ist, kann sie in einem Schritt 204 zu dem Anweisungsspeicher 121 übertragen werden, und irgendwelche gewünschten graphischen Elemente können zu dem Speicherungsspeicher 122 übertragen werden. Die Anweisungen können daraufhin durch die Hardwarearchitektur 120 ausgeführt werden, um ein gerendertes Bild zu erzeugen. Nachdem das Bild gerendert worden ist, kann es durch das Computersystem 125 aus dem Speicherungsspeicher 122 ausgelesen und wie gewünscht gespeichert, angezeigt oder gedruckt werden, wie es bei einem Schritt 205 angegeben ist.

Claims

1. Verfahren zur Interpretation eines Programms für die Erzeugung eines Bilds, wobei das Bild aus mehreren graphischen Elementen besteht und das Programm in einer graphischen Programmiersprache definiert ist, wobei das Verfahren durch einen Computer ausgeführt wird und die Schritte umfaßt:

(a) Aufbauen (201) zumindest eines Ausdrucksbaums, der die zur Erzeugung des Bilds erforderlichen Operationen beschreibt;

(b) automatisches Ändern (202) zumindest eines Abschnitts des Ausdrucksbaums zur Verringerung einer entsprechenden Ausführungszeit einer von dem Ausdrucksbaum abgeleiteten Folge von Anweisungen ohne eine wesentliche Änderung des durch die Ausführung der Folge von Anweisungen erzeugten Bilds; und

(c) Wandeln (203) des geänderten Ausdrucksbaums in eine entsprechende Folge von Anweisungen zur Erzeugung des Bilds;

dadurch gekennzeichnet, daß der Änderungsschritt die Unterschritte umfaßt:

(b) (i) Bestimmen einer alternativen Form von Ausdruck von Abschnitten des zumindest einen Ausdrucksbaums;

(b)(ii) Schätzen eines Aufwands der Ausführung einer entsprechenden Folge von Anweisungen der alternativen Form von Ausdruck; und

(b) (iii) Ändern des Abschnitts zu der alternativen Form von Ausdruck, wenn der Aufwand der Ausführung der alternativen Form des Abschnitts niedriger als der Aufwand der Ausführung einer gegenwärtigen Form des Abschnitts ist;

wobei der Ausdrucksbaum Blattknoten (20, 24) mit zugeordneten graphischen Elementen und innere Knoten (26, 36, 37, 39) mit zugeordneten Codes zur Kombination graphischer Elemente umfaßt, und wobei die Abschnitte innere Knoten umfassen und der Schätzunterschritt die Unterschritte umfaßt:

(b) (ii)(1) Bestimmen der Größe von abstammenden graphischen Elementen, die den Nachfahren des derzeitigen Knotens entsprechen; und

(b) (ii)(2) Bestimmen des Aufwands der Ausführung aus zumindest der Größe der abstammenden graphischen Elemente.

2. Verfahren nach Anspruch 1, ferner mit dem Schritt: (d) Ausführen (204) der Folge von Anweisungen zur Erzeugung des Bilds.

3. Verfahren nach einem der vorstehenden Ansprüche, wobei das Bild aus mehreren graphischen Elementen besteht und die Änderung des Ausdrucksbaums zur Verringerung der Anzahl von Malen, die ein Abschnitt des Bilds gespeichert werden muß, ausgeführt wird.

4. Verfahren nach einem der vorstehenden Ansprüche, wobei zumindest einer der zugeordneten Codes der inneren Knoten assoziativ ist und die alternativen Formen des Ausdrucksbaums assoziative Permutationen der Abschnitte umfassen.

5. Verfahren nach einem der vorstehenden Ansprüche, wobei zumindest einer der zugeordneten Codes der inneren Knoten kommutativ ist und die alternativen Formen des Ausdrucksbaums kommutative Permutationen der Abschnitte umfassen.

6. Verfahren nach einem der vorstehenden Ansprüche, wobei zumindest einer der zugeordneten Codes der inneren Knoten eine entsprechende Umkehrform aufweist und die alternativen Formen des Ausdrucksbaums ein Verwenden der Umkehrform umfassen.

7. Verfahren nach einem der vorstehenden Ansprüche, wobei die Änderung des Ausdrucksbaums im Vergleich zu dem entsprechenden anfänglichen Ausdrucksbaum ein erhöhtes Ausmaß von Rechtsschieflage aufweist.

8. Computervorrichtung (120, 125) zur Interpretation eines Programms für die Erzeugung eines Bilds, wobei das Bild aus mehreren graphischen Elementen besteht und das Programm in einer graphischen Programmiersprache definiert ist, wobei die Vorrichtung umfaßt:

eine Einrichtung zum Aufbauen zumindest eines Ausdrucksbaums, der die zur Erzeugung des Bilds erforderlichen Operationen beschreibt;

eine Einrichtung zum automatischen Ändern zumindest eines Abschnitts des Ausdrucksbaums zur Verringerung einer entsprechenden Ausführungszeit einer von dem Ausdrucksbaum abgeleiteten Folge von Anweisungen ohne eine wesentliche Änderung des durch die Ausführung der Folge von Anweisungen erzeugten Bilds; und

eine Einrichtung zum Wandeln des geänderten Ausdrucksbaums in eine entsprechende Folge von Anweisungen zur Erzeugung des Bilds;

dadurch gekennzeichnet, daß die Änderungseinrichtung umfaßt:

eine Einrichtung zum Bestimmen einer alternativen Form von Ausdruck von Abschnitten des zumindest einen Ausdrucksbaums;

eine Einrichtung zum Schätzen eines Aufwands der Ausführung einer entsprechenden Folge von Anweisungen der alternativen Form von Ausdruck; und

eine Einrichtung zum Ändern des Abschnitts zu der alternativen Form von Ausdruck, wenn der Aufwand der Ausführung der alternativen Form des Abschnitts niedriger als der Aufwand der Ausführung einer gegenwärtigen Form des Abschnitts ist;

wobei der Ausdrucksbaum Blattknoten (20, 24) mit zugeordneten graphischen Elementen und innere Knoten (26, 36, 37, 39) mit zugeordneten Codes zur Kombination graphischer Elemente umfaßt, und wobei die Abschnitte innere Knoten umfassen und die Schätzeinrichtung umfaßt:

eine Einrichtung zum Bestimmen der Größe von abstammenden graphischen Elementen, die den Nachfahren des derzeitigen Knotens entsprechen; und

eine Einrichtung zum Bestimmen des Aufwands der Ausführung aus zumindest der Größe der abstammenden graphischen Elemente.

9. Computervorrichtung nach Anspruch 8, ferner mit: einer Einrichtung zum Ausführen der Folge von Anweisungen zur Erzeugung des Bilds.

10. Computervorrichtung nach einem der Ansprüche 8 und 9, wobei das Bild aus mehreren graphischen Elementen besteht und die Einrichtung zum Ändern des Ausdrucksbaums ferner eine Einrichtung zum Verringern der Anzahl von Malen, die ein Abschnitt des Bilds gespeichert werden muß, umfaßt.

11. Computervorrichtung nach einem der Ansprüche 8 bis 10, wobei zumindest einer der zugeordneten Codes der inneren Knoten assoziativ ist und die alternativen Formen des Ausdrucksbaums assoziative Permutationen der Abschnitte umfassen.

12. Computervorrichtung nach einem der Ansprüche 8 bis 11, wobei zumindest einer der zugeordneten Codes der inneren Knoten kommutativ ist und die alternativen Formen des Ausdrucksbaums kommutative Permutationen der Abschnitte umfassen.

13. Computervorrichtung nach einem der Ansprüche 8 bis 12, wobei zumindest einer der zugeordneten Codes der inneren Knoten eine entsprechende Umkehrform aufweist und die alternativen Formen des Ausdrucksbaums ein Verwenden der Umkehrform umfassen.

14. Computervorrichtung nach einem der Ansprüche 8 bis 13, wobei die Einrichtung zum Ändern des Ausdrucksbaums ferner eine Einrichtung zum Schieflegen des Ausdrucksbaums zur Erhöhung des Ausmaßes von Rechtsschieflage im Vergleich zu dem entsprechenden anfänglichen Ausdrucksbaum umfaßt.

15. Computerprogramm mit Codeeinrichtungen, die bei einer Ausführung in einem Datenverarbeitungssystem ein Verfahren zur Interpretation eines Programms für die Erzeugung eines Bilds ausführen, wobei das Bild aus mehreren graphischen Elementen besteht und das Programm in einer graphischen Programmiersprache definiert ist, wobei das Verfahren die Schritte umfaßt:

(b) automatisches Ändern (202) zumindest eines Abschnitts des Ausdrucksbaums zur Verringerung einer entsprechenden Ausführungszeit einer von dem Ausdrucksbaum abgeleiteten Folge von Anweisungen ohne eine wesentliche Änderung eines durch die Ausführung der Folge von Anweisungen erzeugten Bilds; und

dadurch gekennzeichnet, daß der Änderungsschritt die Unterschritte umfaßt:

(b) (ii) Schätzen eines Aufwands der Ausführung einer entsprechenden Folge von Anweisungen der alternativen Form von Ausdruck; und