DE69406462T2

DE69406462T2 - Objekt-orientiertes graphisches system und dazu gehöriges verfahren

Info

Publication number: DE69406462T2
Application number: DE69406462T
Authority: DE
Inventors: Arthur Cabral; Maire Howard; Rajiv Jain; John Peterson; Robert Seidl; Richard Webb
Original assignee: Taligent Inc
Current assignee: Apple Inc
Priority date: 1993-11-02
Filing date: 1994-01-03
Publication date: 1998-05-28
Anticipated expiration: 2014-01-04
Also published as: US5455599A; EP0727076A1; WO1995012866A1; DE69406462D1; CN1134194A; JPH09504896A; EP0727076B1; AU6023994A; JP3454828B2; CA2169626A1

Description

Gebiet der Erfindung

Diese Erfindung betrifft ein objektorientiertes Graphiksystem, eine Vorrichtung und eine Methode für die Graphikverarbeitung in einem objektorientierten Betriebssystem, das sich in einem Computer befindet.

Hintergrund der Erfindung

Computerbilder oder Zeichnungen, die auf einem Computerbildschirm gezeichnet werden, werden als Computergraphiken bezeichnet. Computer-Graphiksysteme speichern Graphiken intern in digitaler Form. Das Bild wird in winzig kleine Bildelemente oder Pixel aufgeteilt. Somit ist ein Computerbild oder eine Computergraphik eigentlich eine Ansammlung einzelner Bildelemente oder Pixel. Intern, in der digitalen Welt des Computers, wird jedem Pixel ein Satz von digitalen Werten zugeordnet, welche die Attribute des Pixels repräsentieren. Die Attribute eines Pixels können zum Beispiel dessen Farbe, Intensität und Position beschreiben. Um somit die Farbintensität oder Position eines Pixels zu ändern, muß man nur den digitalen Wert für dieses bestimmte Attribut ändern.
Herkömmliche Computergraphiksysteme verwenden geometrische Grundformen, die als Bilder, Bitmaps oder Pixelmaps bekannt sind, um Computerbilder als eine Ansammlung von Pixeln zu repräsentieren. Diese geometrischen Grundformen repräsentieren eine zweidimensionale (2D) Datengruppe von Pixelattributen und deren entsprechenden digitalen Werten. Typischerweise wird eine solche geometrische Grundform als "Strukt" (Datenstruktur) bezeichnet, welche einen Zeiger auf Pixeldaten, eine Pixelgröße, die Größe der Abtastlinie, Grenzen und möglicherweise eine Referenz auf eine Farbtabeile enthält. Sehr oft wird davon ausgegangen, daß die Pixel die Farbluminanz Rot, Grün und Blau (RGB) oder Indizes auf eine Farbtabelle repräsentieren. Somit erfüllen die geometrischen Grundformen einen doppelten Zweck als Rahmenpuffer und als Rahmenspeicherspezifikation.
Die aufkeimende Computergraphikindustrie hat sich auf einen De-Facto-Standard für die Pixeldarstellung geeinigt. Alle Arten von Bildern, die nicht in diesen Standard passen, werden zu "Bürgern zweiter Klasse" degradiert. Herkömmuche Graphiksysteme sind jedoch nicht erweiterbar. Sie sind für gewöhnlich einer bestimmten Anwendung zugeordnet, die an einer bestimmten Klasse von Bildern ausgeführt wird. Dies ist in der heutigen, sich rasch ändernden Umgebung digitaler Technologie nicht akzeptabel. Jeden Tag kommt eine neue Anwendung auf den Markt, und mit ihr der Bedarf an einer neuartigen Verarbeitung und Veränderung neuer Bildarten. Somit ist die Verwendung eines Graphiksystems mit einer nicht erweiterbaren Graphikspezifikation nicht nur kurzsichtig, sondern schlichtweg überholt. Graphische Anwendungen, Attribute und organisatorische Anforderungen für Computerausgabemedien sind vielfältig und nehmen ständig zu. Somit sind dedizierte Einzweck-Graphiksysteme nicht in der Lage, die aktuellen Anforderungen von Anwendungen zu erfüllen. Es besteht ein Bedarf an einem robusten Graphiksystem, welches eine dynamische Umgebung und eine erweiterbare Graphik-Spezifikation zur Verfügung stellt, die entsprechend ausgeweitet werden können, um neue Anwendungen und neue Bildarten zu umfassen und neue Pixelveränderungen zu ermöglichen.
Zum Beispiel ist es nur sehr selten der Fall, daß zwei Anwendungen den selben Satz an Pixelattributen benötigen.
Dreidimensionale (3D) Anwendungen speichern Z-Werte (Tiefenordnung), während Animations- und Zeichensysteme Alpha-Werte speichern. Interaktive Materialeditoren und 3D- Malprogramme speichern 3D-Schattierungsinformationen, während Videoproduktionssysteme YUV 4:2:2 Pixel-Datengruppen erforderlich machen können. Hardware-Begrenzer speichern Schichtenmarkierungen, und ausgeklügelte Systeme können Objektkennungen für die Treffererkennung speichern. Darüber hinaus häufen graphische Attribute, wie zum Beispiel Farbräume, laufend Hinzufügungen an, wie zum Beispiel PhotoYCC . Die Farbabgleichtechnologie ist immer noch im Aufblühen, und es ist noch unklar, welcher quantisierte Farbraum für die Aufzeichnung des sichtbaren Spektrums als Pixel am besten geeignet ist. Es gibt also in der Welt der Graphik eine Vielzahl unterschiedlicher Datentypen. Weiters gibt es auch eine Vielzahl von Speicherorganisationstechniken. Und um das Ganze noch komplizierter zu machen, scheint jede neue Anwendung eine andere Organisation des Pixelspeichers zu benötigen. Zum Beispiel stellen die Abtastlinien- Ausrichtungen von Component Interleaved oder "chunky" die vorherrschende Organisationsart in Macintosh -Videokarten dar, aber der Wechselspeicher mit Component Interleaved- Banken stellt den Trend in Videokarten dar, die für Hosts mit kleinem Adreßraum ausgerichtet sind. Planare Komponentenflächen und verschachtelte Komponentenflächen stellen den Trend in Druckvorstufenanwendungen und elektronischen Malanwendungen dar, aber Aus- und Eingabegeräte, die mit mehrfachen Durchgängen drucken oder abtasten, bevorzugen ein planares Komponentenformat. Formate mit mehrfacher Auflösung oder Pyramidenformate sind häufig im Zusammenhang mit statischen Bildern zu finden, die eine neuerliche Abtastung in Echtzeit benötigen. Darüber hinaus können Bilder, die sehr viel Speicher benötigen, als komprimierte Pixeldaten dargestellt werden, die auf vielerlei Weise kodiert werden können.
Die Vielzahl und das rasche Wachstum bei Graphikanwendungen, Datentypen und Pixelspeicherveränderungen ist sehr groß. Es besteht ein Bedarf an einem Mehrzwecksystem, das mit allen bekannten Anwendungen arbeiten kann und entsprechend erweiterbar ist, um auch für jene Anwendungen einsetzbar zu sein, die derzeit noch nicht bekannt sind. Eine Einzellösung ist unpraktisch. Wenn sie auch jede derzeit bekannte Anforderung erfüllen mag, wäre sie doch sehr groß und unhandlich. Würde eine solche Anwendung verkleinert, dann wäre sie nicht mehr für alle Anwendungen einsetzbar.
Somit besteht ein Bedarf ein einem allgemeinen Graphik-Rahmenwerk, welches die Bedürfnisse vieler Benutzer erfüllt, es aber gleichzeitig dem einzelnen Benutzer ermöglicht, das graphische Allzweck-Rahmenwerk maßzuschneidern.
Dietrich et al., "TGMS An Object-Oriented System for Programming Geometry", SOFTWARE-PRACTICE AND EXPERIENCE, Vol 19, Nr. 10, Oktober 1989, Chichester, UK, Seiten 979-1013, und Woodbury et al., "An Approach to Geometric Reasoning", INTELLIGENT CAD" 1, Proceedings of the IFIP, TC 5/WG 5.2, Workshop on Intelligent CAD, Boston, MA., USA., 6-8 Oktober 1987, Seiten 149-168, offenbaren Anwendungen objektorientierter Konzepte zur Konstruktion von graphischen Systemen und nehmen Bezug auf die Vorteile eines solchen Ansatzes, zu denen auch die einfache Erweiterbarkeit eines graphischen Systems gehört. Beide Referenzen offenbaren die Behandlung geometrischer Klassen von Graphikobjekten und deren Anwendung bei der Modellierung und Darstellung graphischer Anwendungen. Diese Dokumente behandeln nicht das von der Erfindung gelöste Problem.

ZUSAMMENFASSUNG DER ERFINDUNG

Objektorientiertes Design kann ein Allzweck-Rahmenwerk schaffen, welches den Bedürfnissen vieler Benutzer angepaßt ist, es aber gleichzeitig dem einzelnen Benutzer erlaubt, das Allzweck-Rahmenwerk maßzuschneidern und dieses zu erweitern, um bestimmten Anforderungen zu entsprechen. Im allgemeinen kann ein Objekt durch eine Anzahl von Operationen charakterisiert sein, sowie durch einen Zustand, der weiß, wie diese Operationen zur Ausführung gebracht werden. Es ist somit eine Aufgabe der vorliegenden Erfindung, eine Methode und eine Vorrichtung zu schaffen, die ein objektorientiertes Graphik-System schaffen.
Gemäß der Erfindung, wie sie in den Ansprüchen 1, 11 und 15 charakterisiert ist, erstellt ein Prozessor mit einem daran angeschlossenen Anzeigespeicher und einem objektorientierten Betriebssystem ein Komponentenobjekt im Speicher des Prozessors zur Verwaltung der Graphikverarbeitung. Der Prozessor umfaßt ein Objekt für den Anschluß einer oder mehrerer Graphik-Vorrichtungen an verschiedene Objekte, die für Tasks wie zum Beispiel Graphikbeschleuniger, Rahmenpuffer, Seitenbeschreibungs-Sprachen und Vektorprozessoren verantwortlich sind. Das System, die Vorrichtung und die Methode sind gänzlich erweiterbar und ermöglichen eine polymorphe Verarbeitung, die in jedes einzelne Unterstützungsobjekt eingebaut ist.

Kurze Beschreibung der Zeichnungen

Figur 1A ist ein Blockdiagramm eines Personalcomputersystems gemäß einer bevorzugten Ausführungsform;
Figur 1B ist eine hierarchische Darstellung eines Graphik-Anschlusses gemäß einer bevorzugten Ausführungsform;
Figur 2 ist ein Blockdiagramm der Architektur gemäß einer bevorzugten Ausführungsform;
Figur 3 zeigt Beispiele für Graphikerweiterungen von MGraphic gemäß einer bevorzugten Ausführungsform;
Figur 4 stellt MGraphics und deren entsprechende Geometrien gemäß einer bevorzugten Ausführungsform dar;
Figur 5 ist ein Booch-Diagramm, welches den Steuerungsfluß des Graphiksystems gemäß einer bevorzugten Ausführungsform zeigt;
Figur 6 zeigt ein Sternen-Graphikobjekt, das verschiedenen Transformationen gemäß einer bevorzugten Ausführungsform unterzogen wird;
Figur 7 zeigt einen Stern, der über eine Strecke verschoben wird, gemäß einer bevorzugten Ausführungsform;
Figur 8 zeigt die Drehung des Sterns um verschiedene Drehmittelpunkte gemäß einer bevorzugten Ausführungsform;
Figur 9 zeigt die Skalierung eines Sterns um unterschiedliche Skalierungsmittelpunkte gemäß einer bevorzugten Ausführungsform;
Figur 10 zeigt die Auswirkungen der Skalierung eines asymmetrischen Sterns um (-1.0, 1.0) gemäß einer bevorzugten Ausführungsform;
Figur 11 zeigt eine hierarchische Graphik gemäß einer bevorzugten Ausführungsform;
Figur 12 zeigt eine Fahrradgraphik gemäß einer bevorzugten Ausführungsform;
Figur 13 zeigt ein Bolzenobjekt gemäß einer bevorzugten Ausführungsform;
Figur 14 zeigt eine hierarchische Graphik gemäß einer bevorzugten Ausführungsform;
Figur 15 zeigt ein Objekt, das innerhalb des Draw- Aufrufes von TPolygon vorhanden ist gemäß einer bevorzugten Ausführungsform;
Figur 16 zeigt eine Graphikhierarchie, welche die gemeinsame Nutzung zweier oder mehrerer Graphiken gemäß einer bevorzugten Ausführungsform zeigt; und
Figur 17 ist ein Flußdiagramm, welches die detaillierte Logik gemäß einer bevorzugten Ausführungsform zeigt.

Genaue Beschreibung der Erfindung

Die Erfindung wird vorzugsweise im Zusammenhang mit einem Betriebssystem angewandt, das sich auf einem Personalcomputer, wie zum Beispiel dem IBM PS/2 oder einem Apple Macintosh Computer, befindet. Eine repräsentative Hardwareumgebung wird in Figur 1 dargestellt, welche eine typische Hardware-Konfiguration einer Workstation gemäß der vorliegenden Erfindung repräsentiert und eine zentrale Recheneinheit 10, wie zum Beispiel einen herkömmlichen Mikroprozessor, und eine Anzahl anderer Einheiten umfaßt, die über einen Systembus 12 miteinander verbunden sind. Die in Figur 1 dargestellte Workstation umfaßt einen Direktzugriffsspeicher (RAM) 14, einen Nur-Lese-Speicher (ROM) 16, einen E/A-Adapter 18 zum Anschluß von Peripheriegeräten, wie zum Beispiel Platteneinheiten 21 am Bus, einen Benutzerschnittstellenadapter 22 zum Anschluß einer Tastatur 24, einer Maus 26, eines Lautsprechers 28, eines Mikrophons 32 und/oder anderer Benutzerschnittstellengeräte, wie zum Beispiel eines Tast-Bildschirms (nicht dargestellt) am Bus, einen Kommunikationsadapter 34 zum Anschluß der Workstation an einem datenverarbeitenden Netzwerk und einen Anzeigenadapter 36 für den Anschluß des Busses an ein Anzeigegerät 38. Auf der Workstation befindet sich ein Betriebssystern, wie zum Beispiel das Apple System/7 -Betriebssystem.
In einer bevorzugten Ausführungsform wird die Erfindung in der C++-Programmiersprache mit Hilfe objektorientierter Programmiertechniken implementiert. Wie den Fachleuten dieses Bereiches bekannt ist, handelt es sich bei Objektorientierten Programmier- (OOP) Objekten um Software- Einheiten, welche Datenstrukturen und Operationen an den Daten umfassen. Gemeinsam machen diese Elemente die Objekte fähig, nahezu alle Echtwelt-Einheiten in bezug auf ihre Merkmale, repräsentiert durch ihre Datenelemente, und ihr Verhalten, repräsentiert durch ihre Datenmanipulationsfunktionen, zu modellieren. Auf diese Weise können Objekte konkrete Dinge wie Personen und Computer modellieren, und sie können abstrakte Begriffe wie Zahlen oder geometrische Begriffe modellieren. Die Vorteile der Objekt-Technologie ergeben sich aus drei grundlegenden Prinzipien: Einkapselung, Polymorphismus und Vererbung.
Die interne Struktur ihrer Daten sowie die Algorithmen, welche ihren Funktionen zugrunde liegen, werden von den Objekten versteckt oder eingekapselt. Anstatt diese Implementierungseinzelheiten offenzulegen, präsentieren Objekte Schnittstellen, welche ihre Abstraktionen ohne jegliche sonstige unwesentliche Informationen darstellen. Polymorphismus geht bei der Einkapselung einen Schritt weiter. Die Idee dahinter ist: viele Formen, eine Schnittstelle.
Eine Software-Komponente kann eine Anforderung an eine andere Komponente stellen, ohne genau zu wissen, um welche Komponente es sich dabei eigentlich handelt. Die Komponente, welche die Anforderung empfängt, interpretiert diese und bestimmt gemäß ihrer Variablen und Daten, wie die Anforderung auszuführen ist. Das dritte Prinzip ist die Vererbung, welche es Entwicklern ermöglicht, bereits bestehende Konstruktionen und Codes wiederzuverwenden. Durch diese Fähigkeit müssen Entwickler eine Software nicht jedesmal von Beginn an entwickeln. Stattdessen können Entwickler durch Vererbung Unterklassen ableiten, welche ein Verhalten erben, das der Entwickler an die entsprechenden Anforderungen anpassen kann.
Ein Ansatz des Standes der Technik besteht darin, Objekte und Klassenbibliotheken in einer Verfahrensumgebung zu schichten. Viele am Markt befindliche Anwendungsrahmenwerke verwenden diesen Konstruktionsansatz. Bei dieser Konstruktion gibt es eine oder mehrere Objektschichten ganz oben auf einem monolithischen Betriebssystem. Während dieser Ansatz alle Prinzipien der Einkapselung, der Polymorphie und der Vererbung auf die Objektschicht anwendet und eine wesentliche Verbesserung gegenüber Verfahrensprogrammiertechniken darstellt, gibt es bei diesem Ansatz doch auch Einschränkungen. Diese Schwierigkeiten entstehen dadurch, weil es für einen Entwickler zwar einfach ist, die eigenen Objekte wiederzuverwenden, es für ihn aber schwierig ist, Objekte von anderen Systemen zu verwenden, und ein Entwickler immer noch in die internen Nicht-Objekt- Schichten mit prozeduralen Betriebssystem-Aufrufen hineinreichen muß.
Ein weiterer Aspekt des objektorientierten Programmierens ist ein Rahmenwerkansatz für Anwendungsentwicklung. Eine der besten Definitionen von Rahmenwerken stammt von Ralph E. Johnson von der Universität von Illinois und Vincent F. Russo von Purdue. In ihrem Dokument aus dem Jahr 1991 mit dem Titel Reusing Object-Oriented Designs, Universität von Illinois, tech report UIUCDCS91-1696, bieten sie folgende Definition an: "Eine abstrakte Klasse ist eine Konstruktion einer Reihe von Objekten, welche zusammenarbeiten, um eine Reihe von Verantwortlichkeiten auszuführen. Somit besteht ein Rahmenwerk aus einer Reihe von Objektklassen, welche zusammenarbeiten, um festgelegte Reihen von Berechnungsverantwortlichkeiten auszuführen." Vom Standpunkt des Programmierens sind Rahmenwerke im wesentlichen Gruppen miteinander verbundener Objektklassen, die eine zuvor erzeugte Struktur einer Arbeitsanwendung schaffen. So könnte zum Beispiel ein Benutzerschnittstellenrahmenwerk die Unterstützung und das "Standard"-Verhalten des Zeichnens von Fenstern, Rollbalken, Menüs usw. bieten. Da Rahmenwerke auf Objekttechnologie basieren, kann dieses Verhalten geerbt und außer Kraft gesetzt werden, damit Entwickler das Rahmenwerk erweitern und maßgeschneiderte Lösungen in einem bestimmten Bereich ihrer Fachkenntnisse erzeugen können. Dies ist ein wichtiger Vorteil gegenüber dem traditionellen Programmieren, da der Programmierer nicht den ursprünglichen Code verändert, sondern eher die Software erweitert. Darüber hinaus arbeiten sich Entwickler nicht blind durch Schichten von Codes hindurch, weil das Rahmenwerk eine architekturbezogene Führung und Modellierung bietet, gleichzeitig jedoch die Entwickler befreit, damit diese in der Lage sind, spezifische Maßnahmen im Hinblick auf den Problembereich ergreifen zu können.
Von einer geschäftlichen Perspektive her betrachtet können Rahmenwerke als eine Möglichkeit gesehen werden, Fachkenntnisse in einem bestimmten Wissensbereich einzukapseln oder zu verkörpern. Firmeneigene Entwicklungsorganisationen, unabhängige Software-Händler und Systemintegratoren haben sich Fachkenntnisse in bestimmten Bereichen wie zum Beispiel in der Produktion, Buchhaltung oder Währungstransaktionen erarbeitet. Dieses Fachwissen ist in ihrem Code enthalten. Rahmenwerke ermöglichen es Organisationen, die gemeinsamen Merkmale dieses Fachwissens durch Aufnahme in den Code der Organisation aufzunehmen und zu sammeln. Erstens erhalten Entwickler dadurch die Möglichkeit, eine Anwendung zu erstellen oder zu erweitern, welche dieses Fachwissen verwendet; somit wird das Problem einmal gelöst, und die Geschäftsregeln und das Design werden verstärkt und konsistent angewendet. Ebenso verfügen die Rahmenwerke und das hinter den Rahmenwerken enthaltene Fachwissen eine Bedeutung von strategischem Wert für jene Organisationen, die sich in vertikalen Märkten Fachwissen erworben haben, wie zum Beispiel bei der Herstellung, in der Buchhaltung oder in der Biotechnologie, wodurch sie nun über einen Verteilungsmechanismus für die Verpackung, den Wiederverkauf und die Ausnutzung ihres Fachwissens und zur Förderung des Fortschrittes und der Verteilung der Technologie verfügen.
Historisch gesehen haben sich die Rahmenwerke erst in jüngster Zeit als ein Hauptströmungskonzept auf Computerplattformen entwickelt. Diese Migration wurde durch die Verfügbarkeit objektorientierter Sprachen wie zum Beispiel C++ unterstützt. Traditionellerweise wurde C++ am häufigsten auf UNIX-Systemen und den Workstations von Forschern verwendet, und kaum auf Computern in kommerziellen Umgebungen. Sprachen wie C++ und andere objektorientierte Sprachen, wie zum Beispiel Smalltalk und andere, haben einer Reihe von Universitäts- und Forschungsprojekten geholfen, die Vorläufer der heutigen kommerziellen Rahmenwerke und Klassenbibliotheken zu schaffen. Einige Beispiele dafür wären Interviews von der Stanford-Universität, der Andrew- Befehlssatz von der Carnegie-Mellon Universität und das ET++-Rahmenwerk von der Zürich-Universität. Die Arten der Rahmenwerke reichen von Anwendungsrahmenwerken, die bei der Entwicklung von Anwenderschnittstellen helfen, bis hin zu Rahmenwerken niedrigerer Ebene, welche grundlegende Systemsoftwaredienste wie zum Beispiel Kommunikation, Drukken, Dateiablagesystemunterstützung, Graphik usw. bieten. Kommerzielle Beispiele von Anwendungsrahmenwerken sind MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXTstep App Kit (NEXT), und Smalltalk-80 MVC (Parcplace).
Das Programmieren mit Rahmenwerken erfordert von den Entwicklern, die an andere Systemarten gewöhnt sind, eine neue Art des Denkens. Tatsächlich handelt es sich hierbei nicht mehr um das "Programmieren" im herkömmlichen Sinn. In älteren Betriebssystemen, wie zum Beispiel in DOS oder UNIX, schafft das eigene Programm des Entwicklers die gesamte Struktur. Das Betriebssystem bietet Dienstleistungen durch Systemaufrufe - das Programm des Entwicklers führt diese Aufrufe durch, wenn es die Dienstleistung benötigt, und die Kontrolle kehrt wieder zurück, nachdem die Dienstleistung zur verfügung gestellt wurde. Die Programmstruktur basiert auf dem Fluß der Kontrolle, der im Code enthalten ist, den der Entwickler schreibt. Wenn Rahmenwerke verwendet werden, ist dies genau umgekehrt. Der Entwickler ist nicht mehr für den Fluß der Kontrolle verantwortlich. Der Entwickler muß auf die Tendenz verzichten, die Programmieraufgaben in bezug auf den Fluß der Ausführung verstehen zu wollen. Stattdessen muß sich das Denken auf die Verantwortlichkeiten der Objekte richten, welche sich auf das Rahmenwerk verlassen müssen, um zu bestimmen, wann die Tasks ausgeführt werden sollten. Vom Entwickler geschriebene Routinen werden von einem Code aktiviert, den der Entwickler nicht geschrieben hat, und den der Entwickler niemals sieht. Dieser Flipflop-Vorgang im Kontrollfluß kann eine wesentliche psychologische Barriere für Entwickler darstellen, die nur über Erfahrungen im prozeduralen Programmieren verfügen. Wenn dies jedoch einmal begriffen wird, erfordert das Rahmenwerk-Programmieren wesentlich weniger Aufwand als andere Arten des Programmierens.
Ähnlich wie ein Anwendungsrahmenwerk dem Entwickler vorgefertigte Funktionalität bietet, übertragen Systemrahmenwerke, wie zum Beispiel jenes, das in einer bevorzugten Ausführungsform enthalten ist, dasselbe Konzept, indem sie Dienstleistungen auf Systemebene bieten, welche Entwickler, wie zum Beispiel Systemprogrammierer, verwenden, um Unterklassen zu bilden bzw. außer Kraft zu setzen, um maßgeschneiderte Lösungen zu schaffen. Stellen Sie sich zum Beispiel ein Multimedia-Rahmenwerk vor, welches die Grundlage für die Unterstützung von neuen und unterschiedlichen Geräten wie zum Beispiel Audio, Vido, MIDI, Animation usw. bieten sollte. Um dies mit einem Rahmenwerk durchzuführen, muß der Entwickler nur die Eigenschaften und das Verhalten unterstützen, welches dem neuen Gerät eigentümlich ist.
Der Entwickler bietet in diesem Fall eine Implementierung für bestimmte Mitliederfunktione, die vom Multimedie-Rahmenwerk aufgerufen werden. Ein unmittelbarer Vorteil für den Entwickler ist die Tatsache, daß der generische Code, der für die einzelnen Gerätekategorien benötigt wird, bereits vom Multimedia-Rahmenwerk zur Verfügung gestellt wird. Dies bedeutet, daß der Entwickler des Gerätetreibers weniger Code schreiben, testen und weniger Fehler beseitigen muß. Ein weiteres Beispiel für die Anwendung des Systemrahmenwerkes wäre getrennte E/A-Rahmenwerke für SCSIGeräte, NuBuds-Karten und graphische Geräte. Weil es in diesem Zusammenhang eine vererbte Funktionalität gibt, bietet jedes einzelne Rahmenwerk Unterstützung für allgemeine Funktionalitäten, die in seiner Gerätekategorie enthalten sind. Andere Entwickler könnten dann von disen konsistenten Schnittstellen Gebrauch machn, um andere Arten von Geräten zu implementieren.
Eine bevorzugte Ausführungsform übernimmt das Konzept der Rahmenwerke und wendet dieses im gesamten System an. Für den kommerziellen oder firmeninternen Entwickler, den Systemintegrator oder OEM bedeutet dies, daß all die Vorteile, die für eine Rahmenwerk wie zum Beispiel MacApp dargestellt wurden, nicht nur auf die Anwendungsebene für solche Dinge wie Text und Anwenderschnittstellen übertragen werden können, sonder auch auf die Systemebene, für Dienstleistungen wie zum Beispiel Graphiken, Multimedia, Dateisysteme, E/A, Testdurchführung usw. Die Anwendungsstellung in der Architektur einer bevorzugten Ausführungsform ist im wesentlichen gleich wie das Schreiben bereichsspezifischer Teile, die dem Rahmenwerkprotokoll unterstellt sind. Aud diese Weise ändert sich das gesamte Konsept de Programmierens. Anstelle des Schreibens einer Codezeile nach der anderen, welche mehrfache API-Hirarchie aufrufen, wird Software nunmerh entwickelt, indem Klassen von bereits bestehenden Rahmenwerke innerhalb dieser Umgebung abgeleitet werden, und indem danach je nach Bedarf neues Verhalten hinzugefügt und/oder verebtes Verhalten außer Kraft gesetzt wird. Somit wird die Anwendung des Entwicklers zu einer Sammlung von Code, der geschrieben und von allen anderen Rahmenwerkanwendunge gleichermaßen benutzt wird. Dies stellt ein sehr mächtiges Konzept dar, weil Entwickler dadurch ind er Lages sind, auf der Arbeit anderer aufzubauen. Dies gibt dem Entwickler auch die Flexibilität, ein Programm je nach Bedarf mehr oder weniger maßzuschneidern. Manche Rahmenwerke werden genau so verwendet werden, wie sie sind. In manchen Fällen wird das Ausmaß der maßgeschneiderten Anpassung minimal sein, so daß der Teil, den der Entwickler einfügt, klein ist. In andere Fällen kann der Entwickler sehr großzügige Veränderungen durchführen und etwas völlig Neuse schaffen.
In einer bevorzugten Ausführungsform, wie sie in Figur 1 dargestellt ist, verwaltet ein Multimedia-Datenweiterleitungssystem die Bewegung von Multimedia-Informationen durch das Computersystem, während mehrere Medienkomponenten, die sich in RAM 14 bedindet und von der CPU 10 gesteuert werden oder extern über den Bus 12 oder den Kommunikationskanal 34 angeschlossen sind, für die Darstellung der Multimedia-Informationen verantwortlich sind. Es ist kein zentraler Abspieler notwendig, um die gesamte Verabeitung des Systems zu koordinieren oder zu verwalten. Diese Architektur bietet Flexibilität und ermöglicht eine bessere Erweiterbarkeit, wenn neue Medienarten hinzugefügt werden. Ein bevorzugte Ausführungsform stellt ein objektorientiertes Graphik-System dar. Das objetkorientierte Betriebssystem umfaßt eine Anzahl von Objekten, die klar abgegrenzte Teile oder Funktion des Systems darstellen. Jedes Objekt enhält Informationen über sich selbst und eine Reihe von Operationen, die es an seinen eigenen Informationen oder an Informationen, die zu ihm weitergeleitet werden, ausführen kann. Zum Beispiel könnte es ein Objekt mit der Bezeichnung WOMAN gegeben. Die im Objekt WOMAN enthaltenen Informationen bzw. Attribute könnte ALter, Adresse und Beruf umfassen. Diese Attribute beschreiben das Objekt WOMAN. Das Objekt enhält auch ein Reihe von Operationen, die es an den Informationen ausführen kann, welche es enthält. Somit könnte WOMAN ind er der Lage sein, eine Operation auszuführen, um den Beruf von Arzt und Rechtsanwalt zu ändern.
Objekte interagieren miteinander, indem sie Mitteilungen zueinander schicken. Diese Mitteilungen veranlassen, daß das empfangene Objekt eine Maßnahme ausführt, das heißt, eine oder mehrere Operationen durchführt, In der vorliegenden Erfindung gibt es viele miteinander kommunizierende Objekte. Manche der Objekte besitzen gemeisame Merkmale und sind in einer Klasse zusammengefaßt. Eine Klasse ist eine Vorlage, welche die Erzeugung neuer Objekte ermöglicht, die dieselbe Informationen und Operationen enthalten wie andere Mitglieder derselben Klasse. Ein aus einer bestimmte Klasse erzeugtes Objekt wird als eine Instanz dieser Klasse bezeichnet. Die Klasse legt die anfänglich in einer Instanz enthaltenen Operationen und Informationen fest, während der aktuelle Zustand der Instanz ausgeführt werden. Während somit alle Instanzen einer gegebenen Klasse gleich erzeugt werden, können nachfolgende Operationen jede einselne Instanz zu einem einzigartigen Objekt machen.
Polymorphismus bezieht sich auf die objektorientierte Verabeitung, bei der ein Absender eines Stimulus oder einer Mitteilung nichts über die Klasse der empfangenden Instanz wissen muß. der Absender muß nur wissen, daß der Empfänger eine bestimmte Operation ausführen kann, und zwar ohne Hinblick darauf, welche Objekte die Operation ausführt oder zu welcher Klasse es gehört. Instanzen erben die Attribute einer Elternklasse die Attribute der verschiedenen Instanzen modifiziert und die Änderungen von den Unterklassem geerbt. Durch die Beschreibun der Modifizierung an bestehenden Klassen können neue Klassen erstellt werden. Die neue Klasse erbt die Attribute ihrer Klasse, und der Benutzer kann alles das hinzufügen, was die neue Klasse einzigartig macht. Somit läßt sich eine Klasse einfach dadurch definieren, indem festgelegt wird, wodurch sich die neue Klasse oder das Objekt von ihrer Elternklasse bzw. seinem Elternobjekt unterscheidet. Klassen, die in der Erbhierarchie unter einer anderen Klasse liegen, werden als Abkömmlinge oder Kinder der Elternklasse bezeichnet, von der sie abstammen und von der sie Eigenschaften erben. In dieser polymorphen Umgebung obliegt es der Verantwortung des empfangenden Objektes, festzulegen, welche Operation bei Empfang einer stimulierenden Mitteilung auszuführen ist. Eine Operation ist eine Funktion oder Transformation, die an oder von Objekten in einer Klasse ausgeführt werden kann. Das stimulierende Objekt muß nur sehr wenig über das empfangende Objekt wissen, was die Ausführung von Operationen wesentlich vereinfacht. Jedes Objekt muß nur darüber Bescheid wissen, wie es die eigenen Operationen auszuführen hat, und es muß den entsprechenden Aufruf für die Ausführung jener Operationen kennen, die ein bestimmtes Objekt nicht durchführen kann.
Wenn ein und dieselbe Operation für viele unterschiedliche Klassen gilt, handelt es sich um eine polymorphe Operation. Diese selbe Operation nimmt in einer Vielzahl unterschiedlicher Klassen verschiedene Formen an. Eine Methode ist die Implementierung einer bestimmten Operation für eine gegebene Klasse. Zum Beispiel kann die Klasse Document (Dokument) eine Operation mit der Bezeichnung Read (Lesen) enthalten. Abhängig vom Datentyp des Dokumentes, wie zum Beispiel ASCII oder BINÄR, kann eine unterschiedliche Methode zur Ausführung der Read-Operation verwendet werden. Wenngleich also beide Methoden logisch dieselbe Aufgabe ausführen, nämlich Read (Lesen), und somit auch gleich bezeichnet werden, nämlich als Read (Lesen), kann es sich dabei tatsächlich um unterschiedliche Methoden handeln, die von einem jeweils anderen Stück des ausführbaren Codes implementiert werden. Wenngleich die Operation Read Methoden in mehreren Klassen besitzen kann, weist sie doch immer die selbe Anzahl und Art von Argumenten auf, das heißt, ihre Signatur bleibt immer die gleiche. Unterklassen ermöglichen es dem Benutzer, das Allzweck-Rahmenwerk maßzuschneidern. Es ermöglicht unterschiedliche Quantisierungsabsprachen, Sätze von Pixelattributen und eine unterschiedliche Pixelspeicherorganisation. Jede Unterklasse kann das Wissen bezüglich Zuordnung, Verwaltung, Strömung, Übersetzung und Modifizierung ihrer eigenen Pixeldatenklasse einkapseln Alle Untersysteme einer bevorzugten Ausführungsform verwenden polymorphe Zugriffsmechanismen, die es einem Benutzer ermöglichen, Pufferarten zu erweitern, auf die abgebildet oder kopiert werden kann.
Glücklicherweise gibt es einige Gemeinsamkeiten zwischen den unterschiedlichen Pufferarten. Wie sich gezeigt hat, gibt es acht grundlegende Funktionen oder Kategorien, die notwendig sind, um die Mehrzahl der Client-Bedürfnisse zufriedenzustellen. Die meisten Clients verlangen eine polymorphe Verwaltung und die Fähigkeit, die Beziehung zwischen diskretem und kontinuierlichem Raum festzulegen. Clients möchten Farbfähigkeiten für eine exakte Farbwiedergabe charakterisieren. Clients möchten Mechanismen für die Pixelspeicheränderung in Form von Get und Setpixel, spezialisierte "Blit-Schleifen", die für abtastumwandelnde Clients maßgeschneidert sind, Bitbit und CopyImage. Clients möchten Mechanismen, um Clients Varianten zur Verfügung stellen zu können, die zu einem Schlüssel passen, der durch die Kombination von Attributen, die von Clients geliefert werden, geformt werden. Clients verlangen die Fähigkeit, polymorphe Anforderungen bezüglich Eigenschaften oder gespeicherter Attribute ausführen zu können. Clients erfordern Mechanismen, die es Clients erlauben, auf polymorphe Weise Pufferzwischenspeicher zu erstellen, zu warten und abzufragen. Und schließlich erfordern Clients Mechanismen, die es ihnen erlauben, auf polymorphe Weise aufeinander abgestimmte Hintergrundpuffer zu erstellen und zu warten.

Graphikanwendungsprogrammierschnittstelle (API)

Die grundlegenden Komponenten eines Graphiksystems umfassen eine festgelegte Reihe von Geometrischen Grundformen: Point (Punkt), Rectangle (Rechteck), Line (Linie), Curve (Kurve), Polygon (Vieleck), Polyline (Viellinie), Area (Fläche) in 2D, Line (Linie), Polyline (Viellinie), Curve (Kurve) und Surface (Oberfläche) in 3D. Diese Reihe geometrischer Grundformen ist nicht dazu gedacht, vom Benutzer erweitert zu werden. Dies begrenzt die Komplexität der Graphikvorrichtungen niedriger Ebene und führt zu einem "Vertrag" zwischen der API auf Benutzerebene und der Vorrichtung niedriger Ebene für konsistente Daten. Diskretisierte Datensätze: sie umfassen 2D-Rasterbilder mit einer Anzahl möglicher Komponenten und dreiecksförmiger 3D- Datensätze.
Modellierwerkzeuge hoher Ebene: sie können hierarchische Gruppen von Graphikobjekten ausdrücken. Transformationen: diese Objekte repräsentieren die Operationen, die bei herkömmlichen 3x3 (in 2D) oder 4X4 (in 3D) Matrizen verfügbar sind, um Objekte zu drehen, zu skalieren, zu übersetzen usw. Bündel: diese Objekte kapseln die Erscheinungsform der Geometrie ein. Zu den Standardattributen gehören (2D & 3D) Rahmen und/oder Füllfarbe, Stift, Dicke, Strichmuster usw. In 3D legen Bündel auch Schattierungsattribute fest. Über ein Schlüsselwort-/Wertepaar können Benutzerattribute festgelegt werden. Alle numerischen Werte werden im Graphiksystem nach der IEEE-Norm als Gleitkomma mit doppelter Genauigkeit ausgedrückt.
Graphikanschlüsse: ein Graphikanschluß ist eine Ansicht auf Anwendungsebene, welche den Zustand der Anwendung einkapselt. Der Graphikanschluß leitet alle Zeichnungsaufrufe zu einer von mehreren geeigneten Vorrichtungen um (Monitore, Offscreen-Rahmenpuffer, Postscript-Drucker in einem Netzwerk, ein Fenster usw.). Der graphische "Zustand" (aktuelle Transformation, Bündelbegrenzungsbereich usw.) wird auf der Anschlußebene verwaltet. Auf der Vorrichtungsebene ist das System jedoch "zustandslos". In anderen Worten wird der vollständige Zustand für eine bestimmte Abbildungsoperation dann der Vorrichtung präsentiert, wenn diese Abbildung durchgeführt wird. Man beachte, daß eine Vorrichtung sich umdrehen und andere Vorrichtungen aufrufen kann. Zum Beispiel kann eine Vorrichtung für den gesamten Desktop zuerst festlegen, auf welchen Bildschirm die Geometrie fällt, und danach den Abbildungsaufruf für diesen bestimmten Bildschirm starten.

Einführung in die Architektur

In früheren Graphikarchitekturen speichert eine Graphik typischerweise ihren Zustand (wie zum Beispiel Farbe, Übertragungsart, Begrenzungsbereich usw.) privat. Wenn sie zum Zeichnen aufgefordert wird, kopiert die Graphik nach und nach diese Zustandsvariablen in einen Graphikanschluß, wo der Abbildungscode auf sie zugreifen kann. Somit steht der Zustand der Graphik nur während dieser expliziten Zeichenoperation zur Verfügung. Dies ist nicht objektorientiert und stellt eine Einschränkung dar, die sich ein modernes Graphiksystem nicht leisten kann. Eine bevorzugte Ausführungsform schafft ein Rahmenwerk für eine Graphik, um ihren Zustand zu speichern. Das Rahmenwerk unterstützt eine "Ruf' nicht an, wir rufen Dich an"-Architektur, in welcher Clients Zugriff auf den Graphikzustand außerhalb des Kontextes einer bestimmten Funktion erhalten können. Dies ist der Zweck der Graphikanschlußklasse. Es ist eine abstrakte Klasse, welche die Schnittstelle für den Zugriff auf die Zustandsvariablen festlegt. Konkrete Unterklassen legen das tatsächliche Speicherungs- und Verkettungsverhalten der Zustandsvariablen fest.

Graphikanschlußklasse

Ein Design, welches Graphikanschlußklassen verwendet, gruppiert die Graphikzustände in vier unterschiedliche Gruppen, die danach einer einzigen Klasse zugeordnet werden, welche als Graphikanschluß bezeichnet wird. Die vier "Unter-Zustände" sind TGrafBundle, TCoordinateSystem, TClip Boundary und TSceneBundle. Auf ein Graphikanschlußobjekt kann eine Referenz von anderen Klassen hergestellt werden, die Zugriff auf den vollen Graphikzustand benötigen. Zusätzlich dazu kann der Graphikzustand eines Kind-Objektes mit dem Graphikanschlußobjekt seines Eltern-Objektes verknüpft werden, was zur Erzeugung eines neuen Graphikanschlußobjektes führt. Figur 1B ist eine hierarchische Darstellung eines Graphik-Anschlusses gemäß einer bevorzugten Ausführungsform Eine Graphikanschlußklasse enthält auch Methoden für den Zugriff auf ein Gerät und einen Gerätepufferspeicher. Getdevice gibt einen Zeiger zum Gerät zurück, an welches die Darstellung erfolgt. Typischerweise wird dieses Gerät vom Eltern-Graphikanschluß geerbt. GetCache gibt einen Zeiger zum Pufferspeicher zurück, der vom Gerät verwendet wird, um geräteabhängige Objekte zwischenzuspeichern. Dieser Pufferspeicher muß vom Gerät zu einem früheren Zeitpunkt erzeugt worden sein. Der Hauptzweck der Unterklassenbildung vom Graphikanschluß und der vier Unterzustände besteht darin, festzulegen, wie die Speicherung und Verkettung des Graphikzustandes, des Gerätes und des Gerätepufferspeichers erfolgt. Eine einfachere, flache Gruppe von Zustandsvariablen würde nicht flexibel genug sein, um die Maßschneiderung der Zustandsverkettung für eine Untergruppe der Zustandsvariablen zu unterstützen. Auch helfen die Unterzustände dabei mit, die Zustandsvariablen in allgemein verwendete Gruppen aufzuteilen. Zum Beispiel benötigt eine einfache Graphik typischerweise nur ein TGraf-Bundle; komplexere Graphikobjekte können eine Matrix und möglicherweise einen Begrenzungsbereich benötigen.
Eine Graphikklasse wie zum Beispiel MGraphic muß sich selbst für ein TGrafPortDevice hinsichtlich der grundlegenden Gruppe von Geometrien beschreiben, und jede Geometrie muß ein Graphikanschlußobjekt besitzen, das ihr zugeordnet ist. Der Graphikanschluß erlaubt es einem Graphikobjekt, auf komfortable Weise seinen Inhalt in ein TGrafDevice- Objekt zu "leeren". Dies wird ermöglicht, indem eine Gruppe von Zeichenfunktionen in der Graphikanschlußklasse geschaffen wird, welche eine Gruppe von Abbildungsfunktionen in der TGrafDevice-Klasse widerspiegelt. Jede Zeichenfunktion nimmt eine Geometrie und leitet sie und die darin enthaltenen Graphikzustände an den entsprechenden Abbildungsaufruf im Gerät weiter. Für erhöhten Komfort werden auch ein überschreibendes Bündel und eine Modellmatrix weitergeleitet.
Figur 2 ist ein Blockdiagramm der Architektur gemäß einer bevorzugten Ausführungsform. In der bevorzugten Ausführungsform erzeugt eine Modellierschicht 200 Aufrufe an einen Graphikanschluß 210 unter Verwendung der oben beschriebenen API 210. Diese Graphport-Schnittstelle akzeptiert nur eine spezifische, unveränderliche Gruppe von geometrischen Grundformen, wodurch ein "Vertrag" 250 zwischen der API auf Benutzerebene und der API 240 auf der Vorrichtungsebene erstellt wird. Der Graphikanschluß erfaßt die Zustandsinformationen einschließlich der Transformation, der Erscheinungsform ("Bündel") und der Begrenzung in einem polymorphen Pufferspeicher 220, der von mehreren Vorrichtungsarten verwendet wird. Für jeden Abbildungsaufruf werden die Geometrie und alle relevanten, angesammelten Zustandsinformationen 230 der Vorrichtung über ein polymorphes Graphikvorrichtungsobjekt 240 präsentiert. Eine vom Graphikvorrichtungsobjekt 240 verwaltete Vorrichtung kann die Form einer Seitenbeschreibungssprache 260 (wie zum Beispiel Postscript), eines Vektorplottinggerätes 270, eines Gerätes mit benutzerdefinierter elektronischer Hardware zur Abbildung von geometrischen Grundformen 280, eines herkömmlichen Rahmenpuffers 290 oder jeder beliebigen anderen Graphikvorrichtung, wie zum Beispiel Anzeigevorrichtung, Drukker oder Plotter, annehmen.

Modellierungsschicht

Über den Graphikanschluß- und Geometrieschichten befindet sich eine optionale Modellierungsschicht. Eine bevorzugte Ausführungsform schafft eine Modellierungsschicht, aber eine Anwendung kann die standardmäßige überschreiben. Die Standard-Modellierungsschicht wird als "MGraphic"- Schicht bezeichnet. Ein MGraphic-Objekt kapselt sowohl die Geometrie als auch die Erscheinungsform (ein Bündel) ein. Für die Abbildung einer MGraphic wird eine Zeichenmethode verwendet. Diese Methode verwendet den Graphikanschluß, in welchen die MGraphic gezeichnet wird, als Argument. Die MGraphic-Zeichenmethode wandelt diese Informationen in einen Graphikanschlußaufruf um. Das Ziel der Trennung der MGraphic-Schicht von der Graphikanschluß-/Geometrieschicht besteht darin, eine starre Struktur zu vermeiden, die nur für einen Datenbanktyp geeignet wäre. Wenn die von den MGraphic-Objekten zur verfügung gestellte Struktur die Anforderungen des dient nicht erfüllt, ermöglicht die Architektur immer noch die Verwendung einer unterschiedlichen Datenstruktur, solange diese als primitive Geometrien, Bündel und Transformationen ausgedrückt werden kann.

MGraphic-SCHICHT

Das Graphiksystem bietet zwei unterschiedliche Arten zur Abbildung von Geometrien an einer Vorrichtung. Eine Anwendung kann die Geometrie direkt zur Vorrichtung zeichnen. Die Klasse Graphikanschluß unterstützt eine gut definierte, aber unveränderliche Gruppe von 2D-Geometrien. Sie unterstützt diese durch eine Gruppe überladener Zeichenmethoden. Bei Verwendung dieses Ansatzes werden Attribute und Transformationsmatrizen nicht einer Geometrie zugeordnet, wodurch die Eignung nur für eine unmittelbare Abbildung besteht. Der folgende Pseudocode ist ein Beispiel dafür, wie eine Anwendung diesen Ansatz dazu verwenden kann, um eine rote Linie zu zeichnen.
{create a displayport an instance of TGrafPort
TGline line( TGPoint( 0.0, 0.0, TGPoint( 1.0,1.0 ));//Erzeugt eine Linie
TGrafBundle redColor(TRGBColor( 1.0, 0.0, 0.0));//Erzeugt ein rotes //Farbbündel
displayport-)Draw(line, redcolor); 1/Bildet die Linie am Graphport ab}
Alternativ dazu kann eine Anwendung die Geometrie über eine Abstraktion höherer Ebene zeichnen, die als MGraphic bezeichnet wird. Dies ist ein Ansatz mit begrenztem Zustand zur Abbildung graphischer Grundformen. MGraphic ist eine abstrakte Basisklasse zur Darstellung der 2D-Grundformen des Graphiksystems. Es handelt sich dabei um eine Manifestation höherer Ebene von graphischen Objekten, die in einer Sammlung zusammengehalten, transformiert und zu einer Graphikvorrichtung (TGrafDevice) hin abgebildet werden können. Jedes MGraphic-Objekt enthält eine Gruppe seiner eigenen Attribute und stellt eine Strömungsfähigkeit zur Verfügung (mit einigen Einschränkungen bei manchen seiner Unterklassen). Treffertestmethoden bieten einen Mechanismus zur direkten Manipulation von MGraphic-Objekten, wie zum Beispiel das Auslesen (Picking). Durch die Bildung von Unterklassen, einem der Schlüsselmerkmale von MGraphics, ermöglicht MGraphic eine Erweiterbarkeit. Eine bestimmte Unterklasse von MGraphic erzeugt auch Hierarchien von MGraphic- Objekten und bietet die Möglichkeit, das Graphiksystem zu erweitern. Figur 3 zeigt einige Beispiele für Graphikerweiterungen von MGraphic gemäß einer bevorzugten Ausführungsform.
MGraphic ist eine Dienstprogrammklasse für Anwendungen, um geometriebezogene Daten zu enthalten, welche Geometriedefinitionen, grafbundle (ein Satz von graphischen Attributen, welche die Darstellung der Geometrie definieren) und einen Satz von Transformationsmethoden umfassen. MGraphic-Objekte umfassen auch alle anderen Informationen, die von einem Benutzer benötigt werden, und kopieren und strömen diese benutzerspezifischen Daten zu einer Anwendung. Diese Klasse wird nicht unbedingt für Anwendungen benötigt, die nur Interesse an reiner, sofortiger Abbildung haben. Für eine sofortige Abbildung der Grundformen bilden die Anwendungen die Geometrie ab, indem sie ein entsprechendes Geometrieobjekt, ein grafbundle und eine Transformationsmatrix zu einem Graphikanschluß weiterleiten. Figur 4 stellt MGraphics und deren entsprechende Geometrien gemäß einer bevorzugten Ausführungsform dar. Figur 5 ist ein Booch- Diagramm, welches den Steuerungsfluß des Graphiksystems gemäß einer bevorzugten Ausführungsform zeigt. Im Booch- Diagramm von Figur 5 zeigen "Wolken", die mit strichlierten Linien dargestellt sind, Klassen oder Ansammlungen von Klassen (z.B. die Anwendung 500) an. Pfeile, welche Klassen miteinander verbinden, sind von Unterklasse zu Superklasse gerichtet und zeigen eine Hierarchie einschließlich der Eigenschaften von Einkapselung, Vererbung und Polymorphismus an, wie dies in der Objekttechnologie gut bekannt ist, sowie im Fachbereich anerkannte Graphiknotationen, welche beispielhaft dafür sind. Doppellinien zeigen die Verwendung der Klasse bei der Implementierung oder Schnittstelle an. Ein Kreis an einem Ende eines Liniensegmentes zeigt an, daß die Klasse mit dem Kreis am Ende des Liniensegmentes enthalten ist oder verwendet wird. Für eine vollständigere Beschreibung dieser Notation sei auf "Object Oriented Design" von Grady Booch, veröffentlicht von Benjamin/Cummings Publishing Co., Copyright 1991, verwiesen. Die aktuelle MGraphic 520 erbt von MDrawable 510, welche von MCollectible 500 erbt, um das Strömen, die Versionserstellung und anderes Verhalten von MCollectible 500 zu erben. Jede MGraphic 520 besitzt ein Bündel, TGrafBundle 530, welches einen Satz von Attributen enthält. Diese Attribute werden von der MGraphic während der Abbildung verwendet.
Die abstrakte Basisklasse MGraphic repräsentiert nur graphische 2D-Grundformen. Im allgemeinen hat sich gezeigt, daß 2D- und 3D-Grundformen nicht zu einer gemeinsamen Gruppe gehören, sofern nicht die Benutzer die 3D-Ebene löschen, auf der die 2D-Grundformen liegen. 2D- und 3D-Grundformen besitzen unterschiedliche Koordinatensysteme, und ein Vermischen dieser Grundformen würde die Benutzer verwirren. Clients können die zwei Gruppen basierend auf ihren spezifischen Anwendungsanforderungen miteinander mischen. Die Klasse MDrawable 510 ist die abstrakte Basisklasse sowohl von MGraphic 520 als auch von MGraphic3D, welche das gemeinsame Zeichenverhalten der zwei Klassen abstrahiert. Diese Klasse ist für solche Clients von Nutzen, die nur an der Zeichenmethode interessiert sind und keine überladene Funktionalität sowohl für 2D als auch für 3D benötigen.

Zeichenprotokoll MDrawable

Alle MGraphics (2D und 3D) zeichnen an den Graphikanschluß, der als Parameter zu MGraphic weitergeleitet wird. Neben den Zustandsinformationen, die vom GrafPort eingekapselt sind, sind auch alle anderen Informationen im MGraphic-Objekt enthalten. Zu diesen Informationen gehören die Geometrie, das Attributbündel und sämtliche Transformationsinformationen. Alle MGraphics zeichnen synchron und verwalten keine Aktualisierungs- oder Animierungsanforderungen. Es ist Aufgabe des Client, Unterklassen zu erzeugen. Wenn 2D- und 3D-Grundformen als eine Sammlung gezeichnet werden, wie zum Beispiel in einer Liste von MDrawable- Objekten, ist die Zeichenreihenfolge dieselbe, wie wenn 2D- und 3D-Aufrufe am Graphikanschluß gemacht werden. Somit führt das Zeichnen eines 2D-Vielecks, einer 3D-Box und einer 2D-Ellipse je nach der Reihenfolge der Abbildung zu einer jeweils unterschiedlichen Abbildung. Bei der zu diesem Graphikanschluß weitergeleiteten Methode handelt es sich um einen passiven Iterator, auf den jene MGraphic einwirkt, zu der er geleitet wird.

MGraphic-Transformationen

Figur 6 zeigt einen Stern, der verschiedenen Transformationen gemäß einer bevorzugten Ausführungsform unterzogen wird. Transformationen können die Form einer MGraphic durch Skalierung oder Perspektiventransformation ändern, und die Position durch Drehen oder Verschieben. Die Transformationsmethoden ermöglichen es Anwendungen, die Form und Position einer bestehenden MGraphic zu ändern, ohne die MGraphic neu erstellen zu müssen. Alle Transformationsmethoden wenden nur relative Transformationen an der MGraphic an. Die Methoden ScaleBy, MoveBy und RotateBy sind Spezialfälle der allgemeineren Methode TransformBy. Unterklassen wenden die Transformation direkt an der Geometrie an, die sie besitzen, um die Geometrie direkt zu ändern.
Alle MGraphic-Unterklassen sind willkürlichen Transformationen gegenüber verschlossen, d.h., ein Tgpolygon bleibt, auch wenn es von einer willkürlichen Transformation umgewandelt wird, immer noch ein TGPolygon. Bestimmte Geometrien besitzen diese Verschlußeigenschaft jedoch nicht. Zum Beispiel ist ein Rechteck, nachdem es von einer Perspektivenmatrix transformiert wurde, nicht mehr ein Rechteck und besitzt weder eine Definition für die Breite noch für die Höhe. Die ursprüngliche Spezifikation des Rechtecks reicht nicht aus, um die transformierte Version des Rechtecks zu beschreiben. Alle MGraphic-Unterklassen müssen willkürlichen Transformationen gegenüber verschlossen sein. Da alle Transformationen relativ sind, kann eine transformierte MGraphic nicht "zurücktransformiert" werden, indem eine Identitätsmatrix an die MGraphic-Methode TransformBy() weitergeleitet wird.
Figur 7 zeigt einen Stern, der über eine Strecke verschoben wird, gemäß einer bevorzugten Ausführungsform Diese Methode verschiebt die MGraphic über eine Strecke relativ zu ihrer aktuellen Position. Figur 8 zeigt die Drehung des Sterns um verschiedene Drehmittelpunkte gemäß einer bevorzugten Ausführungsform Das Ausmaß der Drehung wird in Grad festgelegt und immer im Uhrzeigersinn durchgeführt. Unterklassen können jedoch das Standardverhalten überschreiben und es für eine spezifische Geometrie und eine bestimmte Verwendung optimieren. Figur 9 zeigt die Skalierung eines Sterns um unterschiedliche Skalierungsmittelpunkte gemäß einer bevorzugten Ausführungsform. Der Faktor ist ein Vektor, der eine ungleichförmige Skalierung ermöglicht, nämlich in X und Y. In Figur 9 ist die X-Koordinate des Parameterwertes gleich (neu x/alt x), und die Y- Koordinate ist gleich (neu y/alt y) Im Falle gleichförmiger Skalierung sind die X- und Y-Koordinaten gleich. Figur 9 zeigt auch die Skalierung um unterschiedliche Skalierungsmittelpunkte.
Negative Skalierungsfaktoren sind möglich, und die Auswirkungen negativer Skalierungsfaktoren sind dieselben wie das Spiegeln. Das Skalieren um -1.0 in der X-Richtung hat die gleiche Auswirkung wie das Spiegeln entlang der Y- Achse, während ein negativer Skalierungsfaktor in der Y- Richtung dieselben Auswirkungen hat wie das Spiegeln entlang der X-Achse hat. Figur 10 zeigt die Auswirkungen der Skalierung eines asymmetrischen Sterns um (-1.0, 1.0) gemäß einer bevorzugten Ausführungsform So wie bei RotateBy() und TranslateBy() sind die Auswirkungen dieser Transformation die gleichen wie die Erstellung einer Skalierungsmatrix und die Weiterleitung derselben zu TransformBy(), und dies ist die Standard-Implementierung. Unterklassen können diese Standard-Implementierung überschreiben und sie für eine spezifische Geometrie und eine bestimmte Verwendung optimieren. Transformby ist eine rein virtuelle Mitgliedsfunktion, welche die MGraphic durch die Matrix transformiert. Alle konkreten Unterklassen von MGraphics müssen diese Mitgliedsfunktion definieren. Unterklassen, welche eine Tgrafmatrix für die Veränderung besitzen, müssen für die richtigen Auswirkungen im Nachhinein die Parametermatrix mit der lokalen Matrix multiplizieren.

MGraphic-Attributbündel

Wie in Figur 5 ersichtlich, besitzen alle MGraphic- Objekte ein ihnen zugeordnetes Attributbündel, das TGraf- Bundle. Dieses Bündel enthält alle Attributinformationen für das Graphikobjekt, wie zum Beispiel seine Farbe, Stifte, und ob es gefüllt ist oder gerahmt. Bei der Erstellung einer MGraphic wird das Grafbundle standardmäßig auf NIL (NULL) gesetzt. Wenn das Grafbundle gleich NIL ist, wird die Geometrie durch einen Standardmechanismus abgebildet. Wenn es in einer Hierarchie verwendet wird, muß das Elternbündel mit dem Bündel des Kindes verkettet werden, bevor das Kind abgebildet wird. Wenn das Bündel eines Kindes gleich NIL ist, verwendet das Kind das Eltern-Bündel für die Abbildung. Zum Beispiel erbt in der Hierarchie von Figur 12 das Objekt E die Attribute von A, C und E, bevor es abgebildet wird, und eine Änderung der Attribute in A setzt sich bis nach unten durch alle seine Kinder fort, nämlich zu B, C, D, E, G, und D.
Es ist wichtig, darauf hinzuweisen, daß einem Bündel eine wesentliche Menge an Informationen zugeordnet ist. Somit wird das Kopieren des Bündels im allgemeinen vermieden. Wenn das Bündel einmal angenommen ist, übernimmt das MGraphic-Objekt die volle Verantwortung, um das Bündel korrekt zu zerstören, wenn das MGraphic-Objekt zerstört wird. Wenn ein Chent ein Attribut eines MGraphic-Objektes verändern möchte, tut er dies, indem er das Bündel zu einem Waisen macht, das Attribut ändert, und danach das Bündel von der MGraphic adoptieren läßt. Auch müssen alle Pufferspeicher, die von Bündeln abhängen, ungültig gemacht werden, wenn das Bündel adoptiert oder zu einem Waisen gemacht wird. Wenn ein Objekt Daten zu Waisen macht, gibt es einen Zeiger zu den Daten zurück und übernimmt für die Daten keine weitere Verantwortung bezüglich der Datenverwaltung. Wenn ein Objekt Daten adoptiert, übernimmt es den Zeiger zum Speicher und übernimmt die volle Verantwortung für die Speicherung. In der Basis-MGraphic-Klasse werden Standard-Implementierungen für alle bündelbezogenen Mitgliedsfunktionen zur Verfügung gestellt, und Unterklassen müssen diese Funktionalität nur dann überschreiben, wenn die Unterklassen einen attributbasierten Pufferspeicher besitzen, der ungültig gemacht oder aktualisiert werden muß, wenn das Bündel adoptiert oder zu einem Waisen gemacht wird. Zum Beispiel müssen die losen Paßgrenzen, wenn sie puffergespeichert werden, ungültig gemacht (oder neu bewertet) werden, wenn sich die Attribute ändern.

C++-Anwendungsprogrammschnittstellen (API) für die Bündelverwaltung

virtual void Adoptbundle(TGrafBundle *bundle)

MGraphic adoptiert das Bündel.

Wenn ein MGraphic-Objekt bereits ein Bündel besitzt, wird dieses gelöscht, wenn das neue Bündel angehängt wird. Wenn Zeiger weitergeleitet werden, ist es für die Clients wichtig, keine Referenzen auf das Bündel zu behalten, die als Parameter weitergeleitet werden. Das MGraphic-Objekt löscht das Bündel, wenn es zerstört wird.

virtual const TGrafBundle* GetBundle() const

Diese Methode ermöglicht es Benutzern, ein Bündel zu erforschen und danach der Reihe nach seine Attribute zu erforschen, indem es sie wiederholt durchläuft. Diese Methode erzeugt einen Alias zu dem Bündel, das im MGraphic-Objekt gespeichert ist.

virtual TGrafBundle* OrphanBundle()

Diese Methode gibt ein Bündel an eine aufrufende Anwendung für deren Gebrauch zurück. Nachdem diese Methode aufgerufen ist, obliegt es der Verantwortung der aufrufenden Anwendung, das Bündel zu löschen, sofern es nicht wieder von einem MGraphic-Objekt adoptiert wird. Wenn es zu einem Waisen gemacht wird, wird das MGraphic-Bündel auf NIL gesetzt, und wenn die Graphik in der Folge gezeichnet wird, verwendet die MGraphic den Standard-Mechanismus der Attribute bzw. Bündel für ihr Eltembündel. Diese Art der MGraphic-Unterklasse referenziert andere MGraphic-Objekte. Wenngleich alles manipulative Verhalten komplexer MGraphic- Objekte einem MGraphic-Objekt ähnlich ist, kapseln diese Objekte die MGraphic-Objekte, auf die sie sich beziehen, nicht vollständig ein. Von den von einer bevorzugten Ausführungsform unterstützten Unterklassen ist TGraphicGroup diejenige, welche in diese Kategorie fällt. TGraphicGroup stammt von der abstrakten Basisklasse TBasegraphicGroup ab, die auf polymorphe Weise die Methoden zur Erzeugung von Iteratoren für die Durchsuchung von Gruppen verfügbar macht. Für Clients, die Gruppen oder Hierarchien erzeugen, ist es wichtig, daß sie von der Basisklasse TBasegraphicGroup abstammen, um den Iterator auf polymorphe Weise verfügbar zu machen. Figur 11 zeigt die Klassenhierarchie gemäß einer bevorzugten Ausführungsform

TBasegraphicGroup-Iteratorunterstützung

Da Graphicgroup die Erzeugung von Hierarchien ermöglicht, ist die Unterstützung für die Iterierung der Hierarchie in diese Basisklasse eingebaut und auf polvmorphe, Weise verfügbar. Diese Methode ist in der abstrakten Basisklasse Tbasegraphicgroup virtuell, und alle Unterklassen ermöglichen eine Implementierung. Unterklassen, die eine Abschirmung für ihre Kinder wünschen, können einen leeren Iterator zurückgeben, wenn diese Mitgliedsfunktion aufgerufen wird.

Protokoll:

TGraphicIterator* CreateGraphicIterator() const = 0

Diese Methode erzeugt einen Graphik-Iterator, der die erste Ebene einer Hierarchie durchläuft. Zum Beispiel erzeugt in Figur 12 der Graphik-Iterator eine konkrete Unterklasse, um B, C und F zu durchlaufen. Für eine weitere Iterierung müssen Iteratoren sowohl für B als auch für C erzeugt werden, da es sich bei diesen um die TBaseGraphicGroups handelt. Alle Unterklassen, die Hierarchien erzeugen, müssen eine konkrete Implementierung zur Verfügung stellen.
TGraphicIterator ist ein aktiver Iterator, der das Durchlaufen der Kinder einer TBaseGraphicGroup ermöglicht.
TGraphicIterator-Methoden umfassen:
const MGraphic *TGraphicIterator::First()
const MGraphic *TGraphicIterator::Next()
const MGraphic *TGraphicIterator::Last()

TGraphicGroup

Das Graphiksystem schafft eine konkrete Unterklasse von TBaseGraphicGroup, nämlich TGraphicGroup, welche die Erzeugung eines Baumes unterstützt. TGraphicGroup erzeugt eine Sammlung von MGraphic-Objekten, welche eine Gruppe bilden. Da jedes der MGraphic-Objekte eine TGraphicGroup sein kann, können Clients eine Hierarchie von Objekten erzeugen. Figur 12 ist ein Beispiel einer Hierarchie, die von TGraphicGroup erzeugt wurde. Figur 12 enthält die TGraphicGroups A, B und C. D, E, F und G sind unterschiedliche einfache MGraphics, die mehr als eine Geometrie einkapseln A besitzt Referenzen zu B, C und F. B bezieht sich auf D, während sich C auf G bezieht. Gruppe C bezieht sich auch auf die MGraphic E. Figur 12 kann als ein vereinfachtes Rad betrachtet werden, wobei sich A auf die MGraphic F bezieht - den Körper des Fahrrads -, und die Gruppen B und C, die sich auf die Transformationen beziehen, welche dem hinteren Rad bzw. dem vorderen Rad zugeordnet sind. Die zwei Räder werden durch die primitiven Geometrien D und G repräsentiert. E repräsentiert die Lenkstange des Fahrrads. Durch Verschiebung des Knotens C werden sowohl das Vorderrad als auch die Lenkstange verschoben, und durch das Verschieben des Knotens A wird das gesamte Eahrrad verschoben. Während zum Zeitpunkt der Abbildung eine Transformationsmatrix an den Kindern angewandt wird, erzeugt die Gruppe ein temporäres GrafPort-Objekt und verkettet dessen Matrix mit jener, die im GrafPort gespeichert ist. Dieser neue GrafPort wird dazu verwendet, um seine Kinder abzubilden, und wird zerstört, sobald das Kind vollständig abgebildet ist. Die Grafport-Objekte werden am Stapel erzeugt. Die Tgraphic Group erlaubt es ihren Kindern nicht, mehr als ein Eltern- Objekt in einem Team zu besitzen. Die TGraphicGroup erbt direkt von MGraphic, und somit besitzt jeder der Knoten sein eigenes grafbundle und kann seine eigene Seite der Hierarchie beeinflussen. Der Destruktor von TGraphicGroup zerstört sich selbst, aber nicht seine Kinder. Es liegt in der Verantwortung einer Anwendung, die Referenzen zu verfolgen und MGraphic-Objekte zu zerstören, wenn sie nicht referenziert werden.

GraphicGroup-Iterator

Eine Graphik-Gruppe ermöglicht eine konkrete Implementierung für die Iterierung ihrer Kinder. Der erzeugte Graphik-Iterator iteriert nur über eine Ebene. Clients, die an einer Iterierung über mehr als eine Ebene hinweg interessiert sind, können dies tun, indem sie Iteratoren an nachfolgenden TGraphicGroups erzeugen.

Attribut- und Transformationshierarchie

Jede TGraphicGroup definiert, wenn sie dies so will, ihre eigenen Attribute und ihre Transformation. Standardmäßig ist ein Attributbündel gleich NIL (NULL), und die Transformationsmatrix wird auf die Identitätsmatrix eingestellt. Da TGraphicGroup eine komplexe MGraphic ist, besitzt sie Referenzen zu anderen MGraphics und deren Kindern. Per definitionem muß jedes der Kinder die Attributeigenschaften und Transformationen seiner Eltern erben. Da jedoch jedes Kind mehrere Referenzen enthalten kann, erbt es diese Attribute durch Verkettung der Elterninformationen zum Zeitpunkt der Abbildung ohne Veränderung der eigenen Attribute. Die Verkettung dieser Attribute erfolgt zum Zeitpunkt des Draw-Aufrufs (Zeichenaufruf). Sowohl das Attribut als auch die Matrix werden mit dem Tgrafport-Objekt verkettet, welches als Parameter zum Draw-Aufruf weitergeleitet wird. In Figur 12 werden Attribute und Transformationen des Objekts A (Körper des Fahrrads) mit dem Graf- Port-Objekt verkettet, welches zu A (als Parameter der Mitgliedsfunktion Draw) weitergeleitet wird, und ein neues Grafport-Objekt, nämlich APortObject, wird am Stapel erzeugt. APortObject wird zum Objekt C weitergeleitet, welches seinen Zustand verkettet und ein neues Anschlußobjekt erzeugt, nämlich CPortObject. Das neue CPortObject wird zum Objekt E weitergeleitet, um abgebildet zu werden. Das Objekt E verkettet seinen Zustand mit CPortObject und bildet sich selbst unter Anwendung des neuen Zustands ab.

MGraphic-BEISPIEL

Als Beispiel wird eine Unterklasse einer Graphik von MGraphic erzeugt, um eine spezielle 2D-Grundform zu erstellen, die einer Draufsicht eines Bolzens entspricht. Diese Klasse speichert eine Transformationsmatrix für ein lokales Koordinatensystem und ist ein sehr einfaches Beispiel ohne Berücksichtigung der Leistung und Effizienz. Figur 13 zeigt ein Bolzenobjekt gemäß einer bevorzugten Ausführungsform. Bei dem untenstehenden Code handelt es sich um einen C++- Quellcode, der das Bolzenobjekt gemäß einer bevorzugten Ausführungsform vollständig definiert.

Der Gerätepufferspeicher

Der Gerätepufferspeicher kann möglicherweise ein großes Objekt sein; daher muß sorgfältig vorgegangen werden, um sicherzustellen, daß sich Gerätepufferspeicher nicht unerwarteterweise über das gesamte System ausbreiten. Wenn dieselbe Basis, GrafPort, für eine Anzahl von Hierarchien verwendet wird, würden die Hierarchien automatisch den Pufferspeicher im Basis-Grafport gemeinsam benutzen.

Graphikzustandsverkettung

Figur 14 zeigt eine hierarchische Graphik gemäß einer bevorzugten Ausführungsform Die Graphik besteht aus einem Polygon und einer Ellipse in einer Gruppe. Jede Graphik in der Hierarchie kann einen Graphikzustand speichern. Zum Beispiel besitzen das Polygon und die Ellipse je ein TGraf-Bundle, während die TGroup keinen Graphikzustand speichert. Diese Architektur ist leicht zu verstehen, bis hierarchische Zustände für Matrizen berücksichtigt werden. Um die richtige Geometrie-Matrix zu erzeugen, muß die lokale Ansichtsmatrix einer Graphik mit der Ansichtsmatrix ihrer Elterngraphik verkettet werden. Diese verkettete Matrix kann dann von der Graphik, welche sie geschaffen hat, zwischengespeichert werden. Der Zustand einer Graphik muß mit jenem ihrer Elterngraphik "verkettet" werden, wodurch eine neue, vollständige Zustandsgruppe entsteht, die für die Graphik gilt. Wenn TGroup::Draw aufgerufen wird, wird das Graphikanschlußobjekt seines Elternobjekts hineingeleitet. Da die TGroup keinen eigenen Zustand besitzt, führt sie nicht jede beliebige Verkettung aus. Sie leitet einfach das Graphikanschlußobjekt ihrer Eltern zum Draw-Aufruf des Polygons und danach zum Draw-Aufruf der Ellipse weiter.
Das Polygon besitzt ein TGrafBundle-Objekt, das mit dem Graphikanschlußobjekt seiner Eltern verkettet werden muß. Dies geschieht durch Erzeugung einer lokalen Graphikanschluß-Unterklasse, welche diese Verkettung durchführen kann. Danach führt es einen Aufruf an TBundleConcatenator.:Draw aus. Figur 15 zeigt ein Objekt, das innerhalb des Draw-Aufrufes von TPolygon vorhanden ist gemäß einer bevorzugten Ausführungsform Weil das TBundleConcatenator-Objekt lokal am Draw-Aufruf von TPolygon erzeugt wird, ist diese Art der Verkettung ihrer Natur nach flüchtig. Diese Verarbeitung wird für bestimmte Typen graphischer Hierarchien benötigt. Zum Beispiel muß eine Graphikhierarchie, welche die gemeinsame Verwendung einer bestimmten Graphik durch zwei oder mehrere andere Graphiken ermöglicht, die flüchtige Verkettung implementieren, da die gemeinsam benutzte Graphik mehrere Eltern besitzt. Figur 16 zeigt eine Graphikhierarchie, welche die gemeinsame Nutzung zweier oder mehrerer Graphiken gemäß einer bevorzugten Ausführungsform zeigt. Das Kurvenobjekt in diesem Beispiel wird von den Graphiken B und C gemeinsam benutzt. Somit muß die Verkettung flüchtig sein, da die Ergebnisse der Verkettung je nach durchgeführter Abzweigung (B oder C) unterschiedlich sein werden.
Graphikobjekte in einer dauerhaften Hierarchie erfordem Kenntnisse von Elterninformationen, die es ermöglichen, daß eine Graphik unter Verwendung des Zustandes ihrer Eltern gezeichnet wird, ohne daß ihre Eltern gezeichnet werden. Eine Graphik in der Hierarchie kann nicht von mehreren Eltern gemeinsam benutzt werden. Zusätzliche Semantik, wie zum Beispiel ein ConcatenateWithParent-Aufruf und ein Draw-Aufruf ohne Parameter, müssen den in der Hierarchie verwendeten Graphikklassen hinzugefügt werden. Ein Graphik kann eine Graphikanschluß-Unterklasse verwenden, die mehr an Zustand speichert, wie zum Beispiel ein Koordinatensystem und Begrenzungsgrenzen. Somit kann jede einzelne Graphik auch ihren eigenen privaten Gerätepufferspeicher behalten.
Figur 17 ist ein Flußdiagramm, welches die detaillierte Logik gemäß einer bevorzugten Ausführungsform zeigt. Die Verarbeitung beginnt beim Funktionsblock 1700, wo ein Modellierungsschichtobjekt vom grafport-Objekt 1740 in eine unveränderliche Gruppe geometrischer Objekte 1730 und eine erweiterbare Gruppe von Graphikattributobjekten 1720 zerlegt wird. Das GrafPort-Objekt 1740 leitet das Geometrie- Objekt 1730 und Graphikattribute 1720 an ein polymorphes Graphikvorrichtungsobjekt 1750 weiter, welches Vorrichtungen (Hardware und Software), wie zum Beispiel ein Seitenbeschreibungssprachen-Objekt 1760, ein Vektorprozessor-Objekt 1770, ein Graphikbeschleuniger-Objekt 1780, ein Rahmenpuffer-Objekt 1790, oder herkömmuchere Graphikvorrichtungen, wie zum Beispiel Anzeigegeräte, Drucker oder Plotter, wie sie in Figur 1 dargestellt werden, verwaltet.

Claims

1. Ein objektorientiertes Graphiksystem, das einen Prozessor (10), einen an den Prozessor angeschlossenen und von diesem gesteuerten Speicher (14), eine Anzeigevorrichtung (38) und eine oder mehrere an den Prozessor angeschlossene und von diesem gesteuerte Graphik-Vorrichtungen (260, 270, 280, 290) aufweist, worin der Speicher eine objektorientierte Anwendung enthält, die Zeichenobjekte umfaßt zur Abbildung graphischer Darstellungen auf besagter Anzeigevorrichtung,

gekennzeichnet durch:

(a) ein Graphik-Vorrichtungsobjekt (TGrafDevice, 240, 1750) in besagtem Speicher für den Betrieb von wenigstens einem Graphik - Vorrichtung;

(b) ein Graphik-Anschluß-Objekt (TGraftPort, 1740) in besagtem Speicher, das einen graphischen Zustand der besagten objektorientierten Anwendung in einem polymorphen Pufferspeicher (220) durch eine Vielzahl von Holen-Befehlen wiedereinfängt und das einen Zeichenbefehl von besagter Anwendung umleitet zu einer geeigneten der besagten Graphik-Vorrichtungen durch einen Satz von Zeichenfunktionen, die einen Satz von Abbildungsfunktionen des besagten graphischen Vorrichtungsobjekts spiegeln;

(c) ein Graphikobjekt (MGraphic, 520) in besagtem Speicher, das Geometrie-Definitionsdaten und einen Satz von Transformationsmethoden enthält zur Änderung der Form einer Geometrie, die durch besagte Geometrie-Definitionsdaten definiert ist, besagtes Graphikobjekt ist mil einem Graphik-Bündelungsobjekt (GrafBundle, 530) verbunden, das Attribut- Informationen enthält, die von besagtem Graphikobjekt zur Abbildungszeit benutzt werden zur Bestimmung der graphischen Darstellung der besagten durch die Geometrie-Definitionsdaten definierten Geometrie; und

(d) Mittel zum Verbinden des besagten Graphik- Vorrichtungsobj ekts mit besagtem Graphik-Anschluß- Objekt zur Ausgabe der besagten graphischen Darstellung der besagten Geometrie auf der besagten einen Graphik-Vorrichtung durch Benutzung der Inhalte des besagten Graphikobjekts und des besagtem Graphik-Bündelungsobjekts.

2. Das System nach nach Anspruch 1, worin besagte Graphik- Vorrichtung ein Graphikbeschleuniger (1780) ist.

3. Das System nach nach Anspruch 1, worin besagte Graphik- Vorrichtung ein Rahmenpuff er (1790) ist.

4. Das System nach nach Anspruch 1, worin besagte Graphik- Vorrichtung ein Seitenbeschreibungs-Sprachen-Objekt (1760) ist.

5. Das System nach nach Anspruch 1, worin besagte Graphik- Vorrichtung ein Vektorprozessor (1770) ist.

6. Das System nach nach Anspruch 1, worin besagtes Graphik- Anschluß-Objekt (TGraftPort, 1740), besagtes Graphik- Vorrichtungsobjekt (TGrafFevice, 240, 1750) und besagtes Graphikobjekt (MGraphic, 520) polymorphe Objekte sind.

7. Das System nach nach Anspruch 1, worin besagtes Graphik- Anschluß-Objekt (TGraftPort, 1740) und besagtes Graphikobjekt (MGraphic, 520) voll ausdehnbar sind.

8. Das System nach nach Anspruch 1 enthält eine Modellierungsschicht (200, 1700) in besagtem Graphikobjekt.

9. Das System nach nach Anspruch 8 enthält ein geometrisches Objekt (1730) und ein Graphik-Attribut-Objekt in besagter Modellierungsschicht.

10. Das System nach nach Anspruch 1, worin besagte Graphik- Vorrichtungsobjekte Anzeigevorrichtungen, Drucker und Plotter enthalten.

11. Ein Verfahren zur Graphik-Verarbeitung in einem objekt-orientierten Betriebssystem eines Computers, der einen Prozessor (10), einen an den Prozessor angeschlossenen und von diesem gesteuerten Speicher (14), eine Anzeigevorrichtung (38) und eine oder mehrere an den Prozessor angeschlossene und von diesem gesteuerte Graphik-Vorrichtungen (260, 270, 280, 290) aufweist, worin der Speicher eine objektorientierte Anwendung enthält, die Zeichenobjekte umfaßt zur Abbildung graphischer Darstellungen auf besagter Anzeigevorrichtung,

gekennzeichnet durch die Schritte:

(a) Erzeugen eines Modellierungsschicht-Objekts (200, 1700), das geometrische Daten und das Aussehen bestimmende Daten einkapselt, welche zur Abbildungszeit zur Bestimmung der graphischen Darstellung der besagten durch die geometrischen Daten definierten Geometrie verwendet werden;

(b) Erzeugen eines Graphik-Vorrichtungsobjekts (TGrafDevice, 240, 1750), das zum Betrieb von wenigstens einer der besagten Graphik-Vorrichtungen dient;

(c) Erzeugen eines Graphik-Anschluß-Objekts (TGraftPort, 1740) in besagtem Speicher, das einen graphischen Zustand der besagten objektorientierten Anwendung in einem polymorphen Pufferspeicher (220) durch eine Vielzahl von Holen-Befehlen einfängt und das einen Zeichnen-Aufruf von besagter Anwendung umleitet zu einer geeigneten der besagten Graphik-Vorrichtungen mittels eines Satzes von Zeichenfunktionen, die einen Satz von Abbildungsfunktionen des besagten Graphik- Vorrichtungsobjekts spiegeln;

(d) Erzeugen von Aufrufen von besagtem Modellierungsschicht-Objekt zu besagtem Graphik-Anschluß-Objekt unter Verwendung eines vorgegebenen Satzes von graphischen Primitiven;

(d) weitergeben der besagten Graphikzustands- Informationen und der Abbildungsinformationen zu besagtem Graphik-Vorrichtungsobjekt zur Ausgabe auf besagter Anzeigevorrichtung.

12. Das Verfahren nach Anspruch 11, worin besagte Graphikzustands-Informationen Transformations-, Aussehens- und Begrenzungsinformationen enthalten.

13. Das Verfahren nach Anspruch 11, worin besagte Graphik-Vorrichtung ein Software- oder Hardwareprozessor ist.

14. Das Verfahren nach Anspruch 11, worin besagtes Modellierungsschicht-Objekt wenigstens ein geometrisches Objekt (1730) und wenigstens ein Graphik-Attribut-Objekt (1720) enthält.

15. Eine Einrichtung zur Verarbeitung von Graphik-Daten, die einen Prozessor (10), einen an den Prozessor angeschlossenen und von diesem gesteuerten Speicher (14), eine Anzeigevorrichtung (38) und eine oder mehrere an den Prozessor angeschlossene und von diesem gesteuerte Graphik-Vorrichtungen (260, 270, 280, 290) aufweist, worin der Speicher eine objektorientierte Anwendung enthält, die Zeichenobjekte umfaßt zur Abbildung graphischer Darstellungen auf besagten Vorrichtungen,

gekennzeichnet durch:

(a) ein Modellierungsschicht-Objekt (200, 1700), das geometrische Daten und das Aussehen bestimmende Daten einkapselt, welche zur Abbildungszeit zur Bestimmung der graphischen Darstellung der besagten durch die geometrischen Daten definierten Geometrie verwendet werden;

(b) ein Graphik-Vorrichtungsobjekt (TGrafDevice, 240, 1750) in besagtem Speicher für den Betrieb von wenigstens einer der besagten Graphik-Vorrichtungen;

(c) ein Graphik-Anschluß-Objekt (TGraftPort, 1740) in besagtem Speicher, das einen graphischen Zustand der besagten objektorientierten Anwendung in einem polymorphen Pufferspeicher (220) durch eine Vielzahl von Holen-Befehlen einfängt und das einen Zeichnen-Aufruf von besagter Anwendung umleitet zu einer geeigneten der besagten Graphik-Vorrichtungen mittels eines Satzes von Zeichenfunktionen, die einen Satz von Abbildungsfunktionen des besagten graphischen Vorrichtungsobjekts spiegeln;

(d) Mittel zum Erzeugen von Aufrufen von besagtem Modellierungsschicht-Objekt zu besagtem Graphik-Anschluß-Objekt unter Verwendung eines vorgegebenen Satzes von graphischen Primitiven;

(e) Mittel zum weitergeben der besagten Graphikzustands- Informationen und der Abbildungsinformationen zu besagtem Graphik-Vorrichtungsobjekt zur Ausgabe auf besagter Graphik-Vorrichtung.

16. Die Einrichtung nach Anspruch 15, worin besagte Graphikzustands-Informationen Transformations-, Aussehens- und Begrenzungsinformationen enthalten.

17. Die Einrichtung nach Anspruch 15, worin besagte Graphik- Vorrichtung ein Vektorprozessor (1770) ist.

18. Die Einrichtung nach Anspruch 15, worin besagte Graphik- Vorrichtung ein Graphikbeschleuniger (1780) ist.

19. Die Einrichtung nach Anspruch 15, worin besagte Graphik- Vorrichtung ein Rahmenpuffer (1790) ist.

20. Die Einrichtung nach Anspruch 15, worin besagte Graphik- Vorrichtung ein Plotter ist.

21. Die Einrichtung nach Anspruch 15, worin besagte Graphik- Vorrichtung ein Drucker ist.

22. Die Einrichtung nach Anspruch 15, worin besagte Graphik- Vorrichtung eine Anzeigevorrichtung ist.

23. Die Einrichtung nach Anspruch 15, worin besagte Graphikvorrichtung ein Seitenbeschreibungs-Sprachen-Prozessor ist.

24. Die Einrichtung nach Anspruch 15, worin besagtes Modellierungsschicht-Objekt wenigstens ein geometrisches Objekt (1730) und wenigstens ein Graphik-Attribut-Objekt (1720) enthält.

25. Die Einrichtung nach Anspruch 15, worin besagte Objekte (200, 1700, Tgraftport, 1740, TGrafDevice, 240, 1750) polymorph und erweiterbar sind.