DE69429417T2

DE69429417T2 - Verfahren und Vorrichtung zum Übereinandergreifen graphischer Objekte

Info

Publication number: DE69429417T2
Application number: DE69429417T
Authority: DE
Inventors: Alex Chung-Hen Chow; John Shih-Yuan Wang
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1993-12-15
Filing date: 1994-10-06
Publication date: 2002-08-22
Anticipated expiration: 2014-10-07
Also published as: JPH07200218A; EP0658859B1; JP2750318B2; EP0658859A3; KR0150832B1; DE69429417D1; KR950020280A; EP0658859A2; US5546524A

Description

Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum Übereinandergreifen graphischer Objekte in einem Computergraphiksystem.
In der Computergraphik müssen zwei- und dreidimensionale graphische Bilder auf einer zweidimensionalen Anzeige angezeigt werden. Im typischen Fall ist eine solche Abbildung ein Konstrukt oder ein Bild, das im Speicher als eine Gruppe von Polygonen gespeichert werden kann. Zur Erzeugung der Abbildung auf der Anzeige werden die Polygone dann mit Hilfe von gewöhnlich sehr rechenintensiven Prozessen aufbereitet. Nun kann es jedoch sein, dass ein Teil des darzustellenden Bildes außerhalb des von einem Fenster der Anzeige oder der Anzeige selbst bereitgestellten Sehfeldes liegt. In diesem Fall kann es wünschenswert sein, das Bild und die Polygone, aus denen das Bild bei seiner Erzeugung zusammengesetzt wird, zu beschneiden, dadurch den Rechenaufwand zu reduzieren und die Aufbereitungsgeschwindigkeit zu erhöhen.
Ein Polygon ist typischerweise eine Gruppe von Eckpunkten P(0), P(1), ..., P(n - 2), P(n - 1), wobei n die Anzahl der Eckpunkte in dem Polygon ist. Jeder Eckpunkt P(i) ist festgelegt durch seine Lage V(i) in einem geeigneten Koordinatenraum und eine Funktion, hier als ein Farbfaktor, f(V(i)), bezeichnet. Ein Farbfaktor ist eine an jedem Eckpunkt ausgewertete Funktion, die später als eine Farbvariation (einschließlich einer Graustufenskala) dargestellt werden kann (beispielsweise eine Lichtintensität, eine Wärmeeigenschaft, ein Feuchtigkeitsfaktor, etc.). Der Farbfaktor kann in eine Farbe umgewandelt werden und ist nützlich bei der Modellierung (beispielsweise einer einfachen Beleuchtungsmodellierung oder einer komplexeren Wettermodellierung).
Nachdem die Polygone aufbereitet sind, kann der User mit den typischen zweidimensionalen Graphiksystemen die Polygone aufnehmen und an die gewünschten Positionen ziehen. Ein Polygon wird aufgenommen, wenn der User dieses Objekt auswählt, und zwar im typischen Fall durch Positionieren eines Cursors über dem Objekt und Drücken einer Maustaste. Das Objekt wird durch Bewegen des Cursors gezogen, typischerweise durch Bewegen der Maus bei gleichzeitigem Drücken der Maustaste. Normalerweise wird das gezogene Objekt beim Ziehen in Umrissen dargestellt, um den Rechenaufwand bei der Aufbereitung des Objekts, während dieses gezogen wird, zu reduzieren. Nachdem der User das Objekt an die gewünschte Stelle gezogen hat, kann er das Objekt hier ablegen, typischerweise durch Loslassen der Maustaste. Bei den bisherigen Systemen wird dann das Polygon am Ablageort aufbereitet. Wenn es an diesem Ablageort bereits Objekte gibt, wird das abgelegte Objekt als über dem bereits vorhandenen Objekt liegend wiedergegeben. Wenn der User wünscht, dass das bereits vorhandene Objekt über dem gerade abgelegten Objekt liegt, muss er das bereits vorhandene Objekt aufnehmen und es dann ohne Ziehen ablegen. Dadurch wird das bereits vorhandene Objekt auf dem soeben gezogenen Objekt plaziert.
Gemäß der vorliegenden Erfindung wird jetzt eine Vorrichtung bereitgestellt zum Bewegen von Objekten in einer Anzeige, wobei die Vorrichtung folgendes umfasst: Speichermittel zum Speichern eines ersten und eines zweiten graphischen Objekts, wobei jedes Objekt eine Priorität hat; Anzeigemittel zum Anzeigen des genannten ersten und des genannten zweiten Objekts auf einer Anzeige, übereinanderliegend entsprechend ihrer jeweiligen Prioritäten; Bewegungsmittel, die auf eine erste Usereingabe reagieren, zum Auswählen und Ziehen des genannten angezeigten ersten Objekts in bezug zu dem genannten angezeigten zweiten Objekt; Erkennungsmittel, die erkennen, ob das genannte erste Objekt mit dem genannten zweiten Objekt kollidiert; gekennzeichnet durch: Modifizierungsmittel, die, in Reaktion auf eine zweite Usereingabe, die Anzeigepriorität des genannten ersten Objekts verändern, wenn das genannte erste Objekt mit dem genannten zweiten Objekt zum ersten Mal kollidiert, wodurch das genannte erste Objekt über oder unter dem genannten zweiten Objekt angezeigt wird, entsprechend der jeweiligen Anzeigepriorität, wie sie durch das genannte Modifizierungsmittel in Reaktion auf eine genannte zweite Ussereingabe geändert wurde.
Betrachtet man die vorliegende Erfindung aus einem anderen Blickwinkel, so wird nun ein Verfahren zum Bewegen graphischer Objekte in einer Anzeige bereitgestellt, wobei das Verfahren folgendes umfasst: Speichern eines ersten und eines zweiten graphischen Objekts, wobei jedes graphische Objekt eine Priorität hat; Anzeigen des genannten ersten und zweiten graphischen Objekts auf einer Anzeige, übereinandergelegt entsprechend ihrer jeweiligen Prioritäten; Auswählen und Ziehen des genannten angezeigten ersten Objekts in Bezug zu dem genannten angezeigten zweiten Objekt, in Antwort auf eine erste Usereingabe; Erkennen, ob das genannte erste Objekt: mit dem genannten zweiten Objekt kollidiert; gekennzeichnet durch: in Reaktion auf eine zweite Usereingabe, Verändern der Anzeigepriorität des genannten ersten Objekts, wenn das genannte erste Objekt mit dem genannten zweiten Objekt zum ersten Mal kollidiert, wodurch das genannte erste Objekt über oder unter dem genannten zweiten Objekt angezeigt wird, entsprechend der jeweiligen Anzeigepriorität, die in Reaktion auf eine zweite Usereingabe geändert wurde.
Ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung soll jetzt unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben werden; es zeigt:
Fig. 1 ein Diagramm eines typischen digitalen Computers, wie er in einem bevorzugten Ausführungsbeispiel der Erfindung genutzt wird;
Fig. 2 ein Blockdiagramm, das die Schichten des Codes zeigt, der typischerweise von dem Hostrechner und dem Graphikadapter verwendet wird, um die Graphikfunktionen auszuführen;
Fig. 3 mehrere angezeigte Polygone, einschließlich konvexer und konkaver Polygone;
Figs. 4A-4D das Ziehen des Objekts C aus Fig. 3 über das Objekt A aus Fig. 3; und
Figs. 5A-5G Flussdiagramme, die das Ziehen eines graphischen Objekts gemäß einem bevorzugten Ausführungsbeispiel der Erfindung erläutern.
Diese Beschreibung beschreibt ein verbessertes Verfahren und eine Vorrichtung zum Übereinandergreifen von Objekten, insbesondere in zweidimensionalen Umgebungen. In dem bevorzugten Ausführungsbeispiel kann der User ein graphisches Objekt über, unter oder sowohl über als auch unter (Übereinandergreifen) ein anderes graphisches Objekt ziehen.
Fig. 1 ist ein Blockdiagramm eines typischen digitalen Computers 100, der von einem bevorzugten Ausführungsbeispiel der Erfindung genutzt wird. Der Computer umfasst Hauptprozessor(en) 110, gekoppelt mit einem Speicher 120 und einer Festplatte 125 in einer Computerbox 105, mit den angeschlossenen Eingabegerät(en) 130 und den Ausgabegerät(en) 140. Der (die) Hauptprozessor(en) 110 kann einen einzelnen Prozessor oder mehrere Prozessoren umfassen. Die (das) Eingabegerät(e) 130 können eine Tastatur, eine Maus, ein Tablett oder ein anderes Eingabegerät umfassen. Die (das) Ausgabegerät(e) kann ein Textmonitor, ein Plotter oder ein anderes Ausgabegerät umfassen. Die computerlesbaren Wechsel- Speichermedien 190, beispielsweise eine Magnetdiskette oder eine Kompaktdisk, können in eine Ein-/Ausgabevorrichtung 180, beispielsweise ein Diskettenlaufwerk oder ein CD-ROM-Laufwerk (Nurlesespeicher für Kompaktdisks), eingelegt werden. Die Daten werden von der E/A-Vorrichtung und gesteuert durch den E/A-Controller 170 von dem Wechsel-Speichermedium gelesen bzw. auf dieses geschrieben. Der E/A-Controller kommuniziert mit dem Hauptprozessor über den Bus 160. Der Hauptspeicher 120, die Festplatte 125 und das Wechsel-Speichermedium 190 werden hier als Speicher zum Speichern von Daten bezeichnet, die vom (von den) Hauptprozessor(en) 110 verarbeitet werden.
Der Hauptprozessor kann über einen Graphikadapter 200 auch mit den Graphik-Ausgabevorrichtung(en) 150, beispielsweise einer Graphikanzeige, gekoppelt sein. Der Graphikadapter 200 empfängt Graphikbefehle aus dem (den) Hauptprozessor(en) 110 über den Bus 160. Der Graphikadapter führt dann diese Befehle mit den (dem) Graphikadapter-Prozessor(en) 220 aus, (der) die mit einem Graphikadapterspeicher 230 gekoppelt (ist) sind. Die Graphikprozessoren in dem Graphikadapter führen dann diese Befehle aus und aktualisieren anhand dieser Befehle den (die) Graphikspeicher 240. Die Graphikprozessoren 220 können auch spezialisierte Aufbereitungshardware zur Aufbereitung bestimmter Zeichenelementtypen umfassen. Der (die) Bildspeicher 240 umfasst Daten für jedes Pixel, das auf der graphischen Ausgabevorrichtung angezeigt werden soll. Ein RAMDAC (random access memory digital-to-analog converter) 250 konvertiert die in den Bildspeichern gespeicherten digitalen Daten in RGB- Signale, die der Graphikanzeige 150 bereitgestellt werden, wodurch die gewünschte Graphikausgabe vom Hauptprozessor aufbereitet wird.
Fig. 2 ist ein Blockdiagramm, das die Schichten des Codes erläutert, der typischerweise vom Hostrechner und Graphikadapter verwendet wird, um die Graphikfunktzonen auszuführen. Ein Betriebssystem 300, beispielsweise UNIX, übernimmt die primäre Steuerung des Hostrechners. Mit dem Betriebssystem ist ein Betriebssystemkern 310 gekoppelt, der die hardwareintensiven Aufgaben des Betriebssystems bereitstellt. Der Betriebssystemkern kommuniziert direkt mit dem Hostrechnermikrocode 320. Der Hostrechnermikrocode ist der primäre Befehlssatz, der vom Hostrechnerprozessor ausgeführt wird. Mit dem Betriebssystem 300 sind die Graphikanwendungen 330 und 332 gekoppelt. Diese Graphikanwendungssoftware kann Softwarepakete wie beispielsweise GL von Silicon Graphic, graPHICS von IBM, PEX von MIT etc. umfassen. Diese Software übernimmt die primären Funktionen zwei-oder dreidimensionaler Graphiken. Die Graphikanwendungen 330 und 332 sind mit der API (application program interface) 340 bzw. 342 der Graphikanwendung gekoppelt. Die API übernimmt viele der rechenintensiven Aufgaben für die Graphikanwendung und bildet eine Schnittstelle zwischen der Anwendungssoftware und der Software, die sich näher an der Graphikhardware befindet, beispielsweise ein Gerätetreiber für den Graphikadapter.
Beispielsweise kann die API 340 und 342 mit einer GAI (graphics application interface) 350 bzw. 352 kommunizieren. Die GAI bildet eine Schnittstelle zwischen der Anwendungs-API und einem Gerätetreiber 370 für den Graphikadapter. In einigen Graphiksystemen übernimmt die API außerdem die Funktion der GAI.
Die Graphikanwendung, die API und die GAI werden vom Betriebssystem und dem Gerätetreiber als ein einziger Prozess betrachtet. Das heißt, die Graphikanwendungen 330 und 332, die API 340 und 342, und die GAI 350 und 352 werden vom Betriebssystem 300 und dem Gerätetreiber 370 als die Prozesse 360 bzw. 362 betrachtet. Die Prozesse werden vom Betriebssystem und vom Gerätetreiber anhand einer Prozesskennung (PID) erkannt, die dem Prozess vom Betriebssystemkern zugewiesen wird. Die Prozesse 360 und 362 können denselben Code verwenden, der zweimal gleichzeitig ausgeführt wird, beispielsweise zwei Ausführungen eines Programms in zwei getrennten Fenstern. Die PID dient zur Unterscheidung der beiden Ausführungen desselben Codes.
Der Gerätetreiber ist ein Graphikkern, der eine Erweiterung des Betriebssystemkerns 310 ist. Der Graphikkern kommuniziert direkt mit dem Mikrocode des Graphikadapters 380. In vielen Graphiksystemen kann die GAI, oder die API, wenn keine GAI- Schicht verwendet wird, direkten Zugriff von der GAI oder API auf den Adaptermikrocode verlangen, indem sie einen ersten Anforderungsbefehl an den Gerätetreiber sendet. Außerdem bieten viele Graphiksysteme die Möglichkeit, dass der Adaptermikrocode einen direkten Zugriff vom Adaptermikrocode auf die GAI oder, wenn keine GAI verwendet wird, die API anfordern kann, indem er einen ersten Anforderungsbefehl an den Gerätetreiber sendet. Beide Prozesse werden hier als Direct Memory Access (DMA) bezeichnet. Ein DMA wird im typischen Fall dann angewendet, wenn große Datenblöcke übertragen werden sollen. DMA ermöglicht die schnellere Übertragung von Daten zwischen dem Hostrechner und dem Adapter, weil dann der Bildschirmtreiber, anders als beim ersten Anforderungsbefehl für den Gerätetreiber zum Einrichten des DMA, umgangen werden kann. In einigen Fällen wendet der Adaptermikrocode die Aufgabenumschaltung an, die es ihm ermöglicht, die momentan vom Adaptermikrocode verwendeten Attribute zu ersetzen. Eine Aufgabenumschaltung wird dann angewendet, wenn der Adaptermikrocode einen Befehl von einer Graphikanwendung empfangen soll, die andere Attribute anwendet, als sie momentan vom Adaptermikrocode angewendet werden. Die Aufgabenumschaltung wird typischerweise von dem Gerätetreiber eingeleitet, der die Attributänderungen erkennt.
Die Blöcke 300-340 sind Softwarecodeschichten, die typischerweise von der Art des verwendeten Graphikadapters unabhängig sind. Wenn beispielsweise von der Graphikanwendungssoftware ein anderer Graphikadapter verwendet werden soll, würde eine neue GAI, ein neuer Graphikkern und ein neuer Adaptermikrocode benötigt. Außerdem sind die Blöcke 300- 370 typischerweise im Hostrechner gespeichert und werden von diesem ausgeführt. Der Adaptermikrocode 380 wird jedoch typischerweise im Graphikadapter gespeichert und von diesem ausgeführt. In einigen Fällen wird jedoch der Adaptermikrocode vom Hostrechner bei der Initialisierung des Graphikadapters in den Graphikadapter geladen.
In typischen Graphiksystemen weist der User die Graphikanwendung an, aus einem zwei- oder dreidimensionalen Modell ein Bild aufzubauen. Der User wählt zuerst die Lage und den Typ der Lichtquellen aus. Anschließend weist der User die Anwendungssoftware an, aus einer Gruppe von vorprogrammierten oder vom User definierten Objekten das gewünschte Modell aufzubauen. Jedes Objekt kann eine oder mehrere koplanare Zeichnungselemente umfassen, die das Objekt beschreiben. Beispielsweise kann eine Gruppe von Zeichnungselementen, z. B. viele Dreiecke, dazu verwendet werden, die Oberfläche eines Objekts zu definieren. Der User stellt dann in einem Fenster eine Perspektive bereit, um das Modell zu betrachten, und definiert dadurch das gewünschte Bild. Die Software beginnt dann mit der Aufbereitung des Bildes aus dem Modell, indem sie Zeichnungselemente, die die Objekte beschreiben, über die API, die GAI und dann den Gerätetreiber, sofern kein DMA eingesetzt wurde, an den Adaptermikrocode sendet. Der Adaptermikrocode bereitet dann das Bild auf der Graphikanzeige auf, indem er diejenigen Zeichnungselemente abschneidet (d. h. nicht verwendet), die in dem Fenster nicht sichtbar sind, und unterteilt jedes verbleibende Zeichnungselement in Pixel, die auf der vom User angegebenen Perspektive sichtbar sind. Die Pixel werden dann in den Bildspeicher geladen, häufig unter Verwendung eines Tiefenspeichers, wenn es sich um ein dreidimensionales Modell handelt. Aufgrund der vielen Zeichnungselemente, Variablen und Pixel ist dieser Schritt sehr rechenintensiv. Das im Bildspeicher gespeicherte und auf der Graphikanzeige angezeigte entstandene Bild trägt nicht die ursprüngliche Information, z. B. von welchem Zeichnungselement oder Objekt das Pixel abgeleitet wurde. Daher kann es sein, dass das Bild teilweise oder im ganzen aufbereitet werden muss, wenn das Fenster, die Userperspektive, das Modell, die Beleuchtung etc., verändert werden.
In dem bevorzugten Ausführungsbeispiel könnte die Ziehtechnik an vielen Stellen genutzt werden, beispielsweise im Adaptermikrocode, der sich in der Nähe des Adapterbildspeichers befindet. Diese Methode wäre auch relativ schnell und ziemlich einfach zu implementieren. Außerdem könnte die Ziehtechnik in der Graphikanwendungssoftware angewendet werden, bei der das aufbereitete Bild auch im Systemspeicher gespeichert wird, entweder bevor oder nachdem das Bild aufbereitet wird, indem der Graphikadapter die Daten an die Graphikanwendungssoftware zurückgibt. Diese Methode wäre zwar viel langsamer, würde jedoch eine Nutzung dieser Technik in den bereits vorhandenen Graphikadaptern ermöglichen. Die Ziehtechnik könnte auch in der Hardware, nämlich im Graphikadapter-Prozessor, implementiert werden. Diese Methode ist extrem schnell, könnte jedoch eine spezialisierte Hardware erforderlich machen. Hiermit wäre ein schnelles Ausschneiden von Zeichnungselementen möglich, die von dem Graphikadapter angezeigt werden sollen. Wie einem Fachmann mit den üblichen Fachkenntnissen klar sein dürfte, würde die vorliegende Technik an vielen anderen Stellen innerhalb des Hostrechners oder Graphikadapters angewendet.
Die meisten Graphikobjekte können als Polygone mit einer Reihe von Eckpunkten beschrieben werden. Das Polygon kann konvex oder konkav sein. Fig. 3 zeigt viele Polygone, darunter konvexe und konkave Polygone, auf einer Anzeige 400. Die Polygone A und C sind konkave Polygone, während das Polygon B ein konvexes Polygon ist. Jedes Polygon wird von einer Reihe von Eckpunkten definiert, die durch Kanten miteinander verbunden sind. Ein Polygon ist konkav, wenn ein Eckpunkt, beispielsweise der Eckpunkt A1, vorhanden ist, der durch das Polygon verdeckt werden kann, wenn dieser Eckpunkt aus dem Polygon entfernt wird. Wenn beispielsweise der Eckpunkt A1 aus dem Polygon A entfernt würde, dann würde durch die neue Linie, die vom Eckpunkt A2 bis zum Eckpunkt A4 verläuft, der vorherige Eckpunkt A1 im Inneren des Polygons liegen. Ein Polygon kann auch als konkaves Polygon definiert werden, wenn der Innenwinkel der Kanten von beliebigen Eckpunkten größer als 180 Grad ist. In Polygon B, das konvex ist, sind beispielsweise alle Innenwinkel an den Eckpunkten kleiner als 180 Grad. Der Innenwinkel am Eckpunkt A1 des Polygons A ist jedoch größer als 180 Grad.
Jedes konkave Polygon kann in eine Reihe von konvexen Polygonen unterteilt werden, indem man jeden konkaven Punkt mit einem anderen Eckpunkt des Polygons verbindet, so dass jeder Teil des Polygons konvex ist. Am Beispiel des Polygons C aus Fig. 3 heißt das, das Polygon kann in drei konvexe Polygone unterteilt werden, indem man das Polygon vom Eckpunkt C4 zum Eckpunkt C7 und vom Eckpunkt C3 zum Eckpunkt C8 unterteilt. Eine andere Methode zur Umwandlung konkaver Polygone in konvexe Polygone ist die Unterteilung eines jeden konkaven Polygons in eine Reihe von Dreiecken. Unter Bezugnahme auf das Polygon C der Fig. 3 heißt das, das Polygon C könnte auch vom Eckpunkt C4 zum Eckpunkt C6 und vom Eckpunkt C3 zum Eckpunkt C1 und vom Eckpunkt C3 zum Eckpunkt C7 unterteilt werden. Außerdem könnten alle Polygone in eine Reihe von Dreiecken unterteilt werden, ohne festzulegen, ob das Polygon konkav oder konvex ist. Hiermit würde sichergestellt, dass alle konkaven Polygone in eine Reihe konvexer Polygone unterteilt werden.
Wenn in dem bevorzugten Ausführungsbeispiel ein Objekt über ein anderes Objekt gezogen wird, kann das gezogene Objekt entweder auf das stationäre Objekt, unter das stationäre Objekt oder in eine Kombination von über und unter dem stationären Objekt gezogen werden, was dann als Übereinandergreifen bezeichnet wird.
Die Figs. 4A-4D erläutern das Ziehen des Objekts C aus Fig. 3 über das Objekt A der Fig. 3. Fig. 4A erläutert, wie das Objekt C mit dem Objekt A an einem Eckpunkt C7 kollidiert. An diesem Punkt gibt der User in dem bevorzugten Ausführungsbeispiel der Erfindung an, ob das Objekt C unter oder über das Objekt A gezogen würde. In dem vorliegenden Beispiel entscheidet sich der User dafür, das Objekt C für diese Kollision unter das Objekt A zu ziehen. Fig. 4B zeigt, wie das Objekt C unter das Objekt A gezogen wird, bis ein zweiter Punkt, Eckpunkt C2, mit dem Objekt A zusammentrifft. An diesem Punkt entscheidet der User, gemäß dem bevorzugten Ausführungsbeispiel der Erfindung, ob dieser Teil des Objekts C unter oder über das Objekt A gezogen wird. In dem vorliegenden Beispiel entscheidet der User, dass dieser Teil des Objekts C über das Objekt A geschoben werden soll. Fig. 4C erläutert Objekt A und C, wo ein Teil des Objekts A über einem Teil des Objekts C liegt und ein anderer Teil des Objekts C über einem Teil von Objekt A liegt. Fig. 4D erläutert einen Zustand, in dem beide Objekte übereinander greifen, in dem Objekt C nicht mehr weiter nach oben gezogen werden kann. Das heißt, unter der Annahme, dass ein Teil des Objekts C über einem Teil des Objekts A liegt, und ein anderer Teil des Objekts C unter einem anderen Teil des Objekts A, muss bei jedem weiteren Ziehen des Objekts C nach oben entweder das Objekt A oder das Objekt C abgeschnitten werden. In dem bevorzugten Ausführungsbeispiel der Erfindung wird ein weiteres Ziehen des Objekts C nach oben verhindert, um die Integrität beider Objekte zu erhalten.
Die Figs. 5A-5G sind Flussdiagramme, die das Ziehen eines graphischen Objekts entsprechend einem bevorzugten Ausführungsbeispiel der Erfindung erläutern. In diesem Flussdiagramm wird angenommen, dass der User mit den Maustasten ein gewünschtes graphisches Objekt aufnimmt und zieht. Für einen Fachmann mit dem üblichen Fachwissen wären jedoch noch andere alternative Verfahren zum Aufnehmen und Ziehen von Objekten denkbar. Graphische Objekte können außerdem aus mehreren Teilen zusammengesetzt sein, um Fälle zu berücksichtigen, in denen graphische Objekte konkav sind und in mehrere konvexe Teile unterteilt wurden, oder Fälle, in denen diese graphischen Objekte eine Sammlung aus mehreren graphischen Objekten sind, die, zusammengefasst, als ein einziges graphisches Objekt gezogen werden sollen. In dem vorliegenden Beispiel hat jeder Teil eines jeden Objekts eine ÜBER_LISTE, um anzuzeigen, welche Teile anderer Objekte über diesem Teil liegen, und eine UNTER_LISTE, um anzuzeigen, welche Teile anderer Objekte unter diesen Teil liegen.
Fig. 5A erläutert die Initialisierungsschritte, wenn ein Objekt vor dem Ziehen durch einen User aufgenommen wird und die vorzugsweise beim Drücken einer Maustaste aufgerufen werden. In Schritt 500 wird der Mausfokus verriegelt, um eine Aufnahme des Objekts, auf das gezeigt wurde, beizubehalten, die aktuelle Position der Maus wird ermittelt, um die Position des Objektumrisses zu berechnen, während das Objekt gezogen wird, der Zeichnungsmodus wird auf XOR gesetzt (was dazu führt, dass das Objekt in dem Moment gelöscht wird, in dem es auf dieselbe Stelle gezogen wird) und die Farbe wird ebenfalls gesetzt, um einen farbigen Umriss des Objekts zu zeigen, während es gezogen wird. In Schritt 510 wird eine Routine ZEICHNE_XOR_FRAME aufgerufen, um den XOR-Frame des Objekts zu zeichnen, bevor das Objekt gezogen wird. Die Routine ZEICHNE_XOR_FRAME wird im Folgenden noch ausführlicher beschrieben. TABELLE 1 enthält den Pseudocode für Fig. 5A. TABELLE 1: Ziehvorgang initialisieren
Fig. 5B erläutert die Schritte, wenn der User beginnt, das Objekt zu ziehen, indem er die Maus bewegt und gleichzeitig die Maustaste gedrückt hält. In einem ersten Schritt 520 wird die neue Position der Maus ermittelt. In einem zweiten Schritt 530 wir die Routine ERKENNE_ÜBERSCHNEIDUNG aufgerufen, um zu bestimmen, ob die Bewegung des Objekts dazu geführt hat, dass es sich mit einem anderen Objekt schneidet oder über dieses greift. Diese Bedingung wird in Schritt 540 geprüft. Wenn es zu einem Übereinandergreifen gekommen ist, darf der User das Objekt nicht weiter ziehen und die Zieh-Routine wird verlassen. In einem alternativen Ausführungsbeispiel wird das überlagerte Objekt so mit dem gezogenen Objekt zusammengefasst, dass beide Objekte zusammen gezogen werden können. Wenn es nicht zu einem Übereinandergreifen kommt, wird die Verarbeitung mit Schritt 550 fortgesetzt. In den Schritten 550 und 560 wird der XOR- Frame des Objekts aus der alten Position gelöscht und dann in der neuen Position neu gezeichnet. In Schritt 570 wird die alte Mausposition mit der neuen Mausposition gleichgesetzt. TABELLE 2 zeigt den Pseudocode für Fig. 5B. TABELLE 2: Graphisches Objekt ziehen
Fig. 5C erläutert die Schritte zur Feststellung, ob das gezogene Objekt oder ein Teil des gezogenen Objekts ein neues Objekt oder einen Teil eines Objekts schneidet. In einem ersten Schritt 600 wird OBJEKT_X auf den ersten Teil des gezogenen Objekts gesetzt (für die Fälle, in denen das gezogene Objekt ein in viele konvexe Objekte untergliedertes konkaves Objekt ist). In Schritt 610 wird OBJEKT_Y auf den ersten Teil des ersten Objekts in dem Fenster gesetzt. In Schritt 620 wird festgestellt, ob die beiden Objekte sich zum ersten Mal schneiden. Hierbei wird ermittelt, ob sich Kanten cer Objekte überschneiden und anschließend wird die ÜBER_LISTE und UNTER_LISTE eines jeden Objekts geprüft um festzustellen, ob es vorher eine Überschneidung gab. Wenn Schritt 620 falsch ist, wird die Verarbeitung in Schritt 650 fortgesetzt, wie weiter unten beschrieben wird. Wenn Schritt 620 wahr ist, wird in Schritt 630 festgestellt, ob die sich schneidenden Kanten eine Innenkante entweder von OBJEKT_X oder von OBJEKT_Y sind. Wenn ja, werden in Schritt 635 die ÜBER_LISTE und die UNTER_LISTE eines jeden Objektes so gesetzt, dass sie der ÜBER_LISTE und UNTER_LISTE eines entsprechenden Teils, der ebenfalls die Innenkante schneidet, entsprechen. Das heißt, wenn OBJEKT_X OBJEKT_Y das erste Mal an einer Innenkante von OBJEKT_Y schneidet, dann muss OBJEKT_X zuvor den anderen Teil geschnitten haben, der sich die Innenkante mit OBJEKT_Y teilt. Wenn OBJEKT_X als unter dem anderen Teil, der die Innenkante berührt, liegend in der Liste steht, müsste OBJEKT_X ebenfalls unter OBJEKT_Y liegen. Wenn Schritt 635 abgeschlossen ist, wird die Verarbeitung mit Schritt 650 fortgesetzt, der weiter unten beschrieben wird. Wenn Schritt 630 falsch ist, dann wird in Schritt 640 festgestellt, ob der User die Taste ALT drückt, um anzuzeigen, dass OBJEKT_X (das gezogene Objekt) unter OBJEKT_Y durchgezogen werden soll. In alternativen Ausführungsbeispielen könnten natürlich noch andere Methoden eingesetzt werden, um anzuzeigen, ob das gezogene Objekt unter oder über andere Objekte gezogen wird. Wenn Schritt 640 falsch ist, dann wird in Schritt 645 OBJEKT_X in der ÜBER_LISTE von OBJEKT_Y aufgeführt, und OBJEKT_Y wird in der UNTER_LISTE von OBJEKT_X aufgeführt. Wenn Schritt 640 wahr ist, dann wird in Schritt 647 OBJEKT_X in der UNTER_LISTE von OBJEKT_Y aufgeführt, und OBJEKT_Y wird in der ÜBER_LISTE von OBJEKT_X aufgeführt. In beiden Fällen wird die Verarbeitung mit Schritt 650 fortgesetzt. In Schritt 650 wird OBJEKT_Y auf den nächsten Teil eines Objekts In dem Fenster gesetzt. In Schritt 655 wird festgestellt, ob der letzte Teil eines Objekts in dem Fenster verarbeitet wurde. Wenn nicht, kehrt die Verarbeitung zu Schritt 620 zurück. Wenn ja, wird in Schritt 660 OBJEKT_X auf den nächsten Teil des gezogenen Objekts gesetzt. In Schritt 665 werden alle Einträge der vorherigen OBJEKT_X ÜBER_LISTE und UNTER_LISTE geprüft, um festzustellen, ob alle anderen in der Liste aufgeführten Teile immer noch überschneiden. Diese Überprüfung könnte einfach dadurch erfolgen, dass jeder Eintrag in den Listen während der oben beschriebenen Schritte 620-650 mit einem Merker (flag) gekennzeichnet wird. Wenn sich nicht überschneidende Einträge vorhanden sind, könnten diese entsprechend dem bevorzugten Ausführungsbeispiel in allen Listen gelöscht werden. Hierdurch kann der User zunächst angeben, dass ein gezogenes Objekt über einem zweiten Objekt liegt, das gezogene Objekt so weit zurückziehen, dass es sich nicht mehr mit dem zweiten Objekt schneidet, so dass die Einträge in den Listen beider Objekte gelöscht werden, und anschließend das gezogene Objekt unter das zweite Objekt ziehen. In Schritt 670 wird festgestellt, ob alle Teile von OBJEKT_X verarbeitet wurden. Wenn nicht, kehrt die Verarbeitung zu Schritt 610 zurück. Wenn ja, wird die Routine ERKENNE_ÜBEREINANDERGREIFEN aufgerufen. Die Routine ERKENNE_ÜBEREINANDERGREIFEN wird im Folgenden ausführlich beschrieben. TABELLE 3 zeigt den Pseudocode für Fig. 5C. TABELLE 3: Überschneidungsbedingung ermitteln
Fig. 5 erläutert die Schritte, mit denen festgestellt wird, ob eine Bedingung vorhanden ist, in der die Objekte übereinander greifen. In einem ersten Schritt 700 wird eine ÜBEREINANDERGREIF_FLAG auf falsch gesetzt, OBJEKT_X wird als das gezogene Objekt gesetzt, und OBJEKT_Y wird als das erste Objekt in dem Fenster gesetzt. In Schritt 705 wird ECKPUNKT_V als der erste Eckpunkt von OBJEKT_Y gesetzt. In Schritt 710 wird festgestellt, ob OBJEKT_X ECKPUNKT_V von OBJEKT_Y zum ersten Mal angetroffen hat, oder ob OBJEKT_Y ECKPUNKT_V von OBJEKT_X zum ersten Mal angetroffen hat (alle Eckpunkte sowohl von OBJEKT_Y als auch von OBJEKT_X werden als ECKPUNKT_V überprüft). Wenn nicht, wird die Verarbeitung mit dem im folgenden beschriebenen Schritt 730 fortgesetzt. Wenn Schritt 710 wahr ist, wird in Schritt 715 bestimmt, ob ECKPUNKT_V sich in einem konkaven Abschnitt seines Objekts befindet (OBJEKT_Y oder OBJEKT_X), und ob eine Übereinandergreif-Bedingung vorliegt. Unter der Annahme, dass ECKPUNKT_V ein Eckpunkt von OBJEKT_Y ist, liegt eine Übereinandergreif-Bedingung dann vor, wenn OBJEKT_X sich über einem Teil von OBJEKT_Y befindet und OBJEKT_X außerdem unter einem zweiten Teil von OBJEKT_Y liegt, und beide Teile von OBJEKT_Y ECKPUNKT_V enthalten. Unter der Annahme, dass ECKPUNKT_V ein Eckpunkt von OBJEKT_X ist, liegt eine Übereinandergreif-Bedingung dann vor, wenn OBJEKT_Y sich über einem Teil von OBJEKT_X befindet und OBJEKT_Y außerdem unter einem zweiten Teil von OBJEKT_X liegt, und beide Teile von OBJEKT_X ECKPUNKT_V enthalten. Wenn Schritt 715 falsch ist, liegt keine Übereinandergreif-Bedingung vor und die Verarbeitung wird mit dem im folgenden Text beschriebenen Schritt 730 fortgesetzt. Wenn Schritt 715 wahr ist, liegt eine Übereinandergreif-Bedingung vor und die Verarbeitung wird mit Schritt 720 fortgesetzt. In Schritt 720 wird die ÜBEREINANDERGREIF_FLAG auf WAHR gesetzt und die Verarbeitung wird mit Schritt 730 fortgesetzt. In Schritt 730 wird ECKPUNKT_V auf den nächsten Eckpunkt von OBJEKT_Y oder OBJEKT_X gesetzt (nachdem alle Eckpunkte von OBJEKT_Y verarbeitet wurden). In Schritt 735 wird festgestellt, ob alle Eckpunkte von OBJEKT_Y und OBJEKT_X verarbeitet wurden. Wenn nicht, kehrt die Verarbeitung zu Schritt 710 zurück. Wenn ja, wird in Schritt 740 OBJEKT_Y auf das nächste Objekt in dem Fenster gesetzt. In Schritt 745 wird festgestellt, ob alle Objekte in dem Fenster verarbeitet wurden. Wenn nicht, kehrt die Verarbeitung zu Schritt 705 zurück. Wenn ja, wird die Verarbeitung für diese Routine gestoppt. Der Pseudocode für Fig. 5D ist in TABELLE 4 dargestellt. TABELLE 4: Übereinandergreif-Bedingung erkennen
Fig. 5E erläutert die Beendigungsschritte, wenn der User das Ziehen des graphischen Objekts beendet, und die aufgerufen werden, wenn die Maustaste losgelassen wird. In Schritt 800 wird der Mausfokus entriegelt, wodurch die Aufnahme des Objekts freigegeben wird. In Schritt 810 wird die Routine ZEICHNE_XOR_FRAME aufgerufen, um den letzten XOR-Frame des Objekts an der aktuellen Mausposition zu löschen. In Schritt 620 wird der Zeichnungsmodus vom XOR-Modus in den Kopiermodus zurückgesetzt. In Schritt 630 wird die Routine OBJEKT_NEUANZEIGEN aufgerufen, um das Objekt an der endültigen Mausposition in seiner vollen Form neu zu zeichnen. Die Routine OBJEKT_NEUANZEIGEN wird im Folgenden unter Bezugnahme auf 5G noch ausführlich beschrieben. Der Pseudocode für Fig. 5E ist in TABELLE 5 wiedergegeben. TABELLE 5: ZIEHVORGANG BEENDEN
Fig. 5F erläutert die Schritte zum Zeichnen des gezogenen Objekts und wird von den oben beschriebenen Routinen aufgerufen. In Schritt 850 wird TEIL_A auf den ersten Teil von OBJEKT_X gesetzt (hiermit soll der Fall behandelt werden, in dem OBJEKT_X konkav ist und in mehrere konvexe Teile unterteilt wurde, oder OBJEKT_X eine Sammlung graphischer Objekte ist). In Schritt 860 wird OBJEKT_Y auf das erste Objekt der ÜBER_LISTE gesetzt. In Schritt 870 wird TEIL A von OBJEKT_Y abgeschnitten und OBJEKT_Y wird auf den nächsten Teil der ÜBER_LISTE gesetzt. In Schritt 875 wird festgestellt, ob alle Teile der oberen Liste verarbeitet wurden. Wenn nicht, kehrt die Verarbeitung zu Schritt 870 zurück, andernfalls wird die Verarbeitung mit Schritt 880 fortgesetzt. In Schritt 880 wird TEIL_A auf den nächsten Teil von OBJEKT_X gesetzt. In Schritt 885 wird festgestellt, ob alle Teile von OBJEKT_X verarbeitet wurden. Wenn nicht, kehrt die Verarbeitung zu Schritt 860 zurück, andernfalls wird die Verarbeitung gestoppt. Der Pseudocode für Fig. 5F wird in TABELLE 6 bereitgestellt. TABELLE 6: XOR-Frame des Objekts zeichnen
Fig. 5G erläutert die Schritte zum erneuten Anzeigen eines gezogenen Objekts in einem Fenster und wird von der oben beschriebenen Routine aufgerufen. In Schritt 900 wird das gezogene Objekt gezeichnet und TEIL_A wird als der erste Teil des gezogenen Objekts gesetzt. In Schritt 910 wird der erste Eintrag der ÜBER_LISTE von TEIL_A abgerufen. In Schritt 920 wird das Objekt, das den ausgewählten Teil, der in der ÜBER_LISTE von TEIL_A aufgeführt ist, enthält, angezeigt. Außerdem wird der nächste Eintrag der ÜBER_LISTE von TEIL_A abgerufen. In Schritt 925 wird ermittelt, ob alle Einträge in der ÜBER_LISTE von TEIL_A verarbeitet wurden. Wenn nicht, kehrt die Verarbeitung zu Schritt 920 zurück. Wenn ja, wird in Schritt 930 TEIL_A auf den nächsten Teil des gezogenen Objekts gesetzt. In Schritt 935 wird festgestellt, ob alle Teile des gezogenen Objekts verarbeitet wurden. Wenn nicht, kehrt die Verarbeitung zu Schritt 910 zurück. Wenn ja, endet die Verarbeitung. Der Pseudocode für Fig. 5G ist in TABELLE 7 wiedergegeben. TABELLE 7: OBJEKT ERNEUT ANZEIGEN

Claims

1. Vorrichtung (200) zum Bewegen graphischer Objekte (A, B, C) in einer Anzeige (150), wobei die Vorrichtung (200) folgendes umfasst:

Speichermittel (230) zum Speichern der genannten ersten und zweiten graphischen Objekte, wobei jedes graphische Objekt eine Priorität hat;

Anzeigemittel zum Anzeigen (560) der genannten ersten und der genannten zweiten Objekte auf einer Anzeige, überlagert entsprechend ihren jeweiligen Prioritäten;

Bewegungsmittel, die auf eine erste Usereingabe ansprechen, zum Auswählen und Ziehen (520) des genannten angezeigten ersten Objekts in Bezug zu dem genannten angezeigten zweiten Objekt;

Erkennungsmittel zum Erkennen (620), ob das genannte erste Objekt mit dem genannten zweiten Objekt kollidiert;

gekennzeichnet durch:

Modifizierungsmittel zum Verändern (647, 645), in Reaktion auf eine zweite Usereingabe, der Anzeigepriorität des genannten ersten Objekts, wenn das genannte erste Objekt mit dem genannten zweiten Objekt zum ersten Mal kollidiert, wodurch das genannte erste Objekt über oder unter dem genannten zweiten Objekt angezeigt wird, entsprechend der jeweiligen Anzeigepriorität, die von dem genannten Modifizierungsmittel in Antwort auf eine zweite Usereingabe geändert wurde.

2. Vorrichtung nach Anspruch 1, bei der

das Speichermittel (230) jedes der genannten graphischen Objekte als ein oder mehrere graphische Teilobjekte speichert, wobei jedes Teilobjekt eine Priorität hat;

das genannte Anzeigemittel die genannten Teilobjekte anzeigt (560), überlagert entsprechend ihrer jeweiligen Prioritäten;

das genannte Erkennungsmittel erkennt (620), ob ein Teilobjekt des genannten ersten Objekts mit einem Teilobjekt des genannten zweiten Objekts zum ersten Mal kollidiert; und

das genannte Modifizierungsmittel die Anzeigepriorität des genannten Teilobjekts des genannten ersten Objekts entsprechend einer Usereingabe verändert (647,645).

3. Vorrichtung nach Anspruch 2, weiter umfassend Mittel zum Speichern einer ÜBER_LISTE für jede der genannten graphischen Teilobjektprioritäten, um anzuzeigen, welche anderen Teilobjekte über diesem Teilobjekt liegen, und einer UNTER_LISTE, um anzuzeigen, welche anderen Teilobjekte unter diesem Teilobjekt liegen, wodurch das Erkennungsmittel die ÜBER_LISTE und die UNTER_LISTE eines jeden graphischen Objekts prüft (620), um festzustellen, ob eine vorherige Kollision stattgefunden hat.

4. Vorrichtung nach Anspruch 2 oder 3, weiter umfassend Erkennungsmittel, um eine Übereinandergreif-Bedingung zu erkennen (715), wenn ein Teilobjekt des genannten ersten Objekts über dem genannten zweiten Objekt liegt und ein anderes Teilobjekt des genannten ersten Objekts unter dem genannten zweiten Objekt liegt.

5. Vorrichtung nach Anspruch 4, bei der das genannte Bewegungsmittel weiter Mittel umfasst, um das Ziehen des genannten ersten Objekts bei Erkennen einer Übereinandergreif-Bedingung zu verhindern.

6. Vorrichtung nach Anspruch 4, bei der das genannte Bewegungsmittel weiter Mittel umfasst, um sowohl das genannte erste als auch das genannte zweite Objekt bei Erkennen einer Übereinandergreif-Bedingung zu bewegen.

7. Ein Verfahren zum Bewegen graphischer Objekte (A, B, C) in einer Anzeige (150), wobei das Verfahren folgendes umfasst:

Speichern (230) eines ersten und eines zweiten graphischen Objekts, wobei jedes graphische Objekt eine Priorität hat;

Anzeigen (560) des genannten ersten und zweiten Objekts auf einer Anzeige, überlagert entsprechend ihrer jeweiligen Prioritäten;

Auswählen und Ziehen (520) des genannten angezeigten ersten Objekts in Bezug zu dem genannten angezeigten zweiten Objekt, in Antwort auf eine erste Usereingabe;

Erkennen (620), ob das genannte erste Objekt mit dem genannten zweiten Objekt kollidiert;

gekennzeichnet durch:

in Antwort auf eine zweite Usereingabe, Verändern (647, 645) der Anzeigepriorität des genannten ersten Objekts, wenn das genannte erste Objekt mit dem genannten zweiten Objekt zum ersten Mal kollidiert, wodurch das genannte erste Objekt über oder unter dem genannten zweiten Objekt angezeigt werden kann, entsprechend ihrer jeweiligen Anzeigepriorität, die entsprechend einer zweiten Usereingabe modifiziert wurde.

8. Ein Verfahren nach Anspruch 7, bei dem

in dem Speicherschritt jedes der genannten graphischen Objekte als ein oder mehrere Teilobjekte gespeichert wird (230), wobei jedes Teilobjekt eine Priorität hat;

in dem Anzeigeschritt die genannten Teilobjekte angezeigt werden (560), überlagert entsprechend ihrer jeweiligen Prioritäten;

in dem Erkennungsschritt erkannt wird (620), ob ein Teilobjekt des genannten ersten Objekts mit einem Teilobjekt des genannten zweiten Objekts zum ersten Mal kollidiert; und

in dem genannten Veränderungsschritt, in Reaktion auf eine Usereingabe, die Anzeigepriorität des genannten Teilobjekts des genannten ersten Objekts geändert wird (647, 645).

9. Ein Verfahren nach Anspruch 8, weiter umfassend:

für jede der genannten graphischen Teilobjektprioritäten, Speichern einer ÜBER_LISTE, um anzuzeigen, welche anderen Teilobjekte über diesem Teilobjekt liegen, uni einer UNTER_LISTE, um anzuzeigen, welche anderen Teilobjekte unter diesem Teilobjekt liegen, wodurch der Erkennungsschritt die ÜBER_LISTE und die UNTER_LISTE eines jeden der genannten graphischen Objekte prüft (620), um festzustellen, ob es zu einer vorherigen Kollision gekommen ist.

10. Ein Verfahren nach Anspruch 8 oder 9, weiter umfassend:

Erkennen (715) einer Übereinandergreif-Bedingung, wenn ein Teilobjekt des genannten ersten Objekts über dem genannten zweiten Objekt liegt, und ein anderes Teilobjekt des genannten ersten Objekts unter dem genannten zweiten Objekt liegt.

11. Ein Verfahren nach Anspruch 10, bei dem der genannte Ziehschritt das Ziehen des genannten ersten Objekts bei Erkennen einer Übereinandergreif-Bedingung verhindert.

12. Ein Verfahren nach Anspruch 10, bei der der genannte Ziehschritt sowohl das genannte erste als auch das genannte zweite Objekt bei Erkennen einer Übereinandergreif-Bedingung zieht.