Method and apparatus for interlocking graphical objects

Abstract

An apparatus for moving graphical objects including a display for displaying multiple graphical objects according to a display priority, apparatus for moving, responsive to a user input, a displayed graphical object, and apparatus for modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved so that the moved graphical object is displayed under a portion of a second displayed graphical object. In addition, a method for moving graphical objects including displaying multiple graphical objects according to a display priority on a display, moving, responsive to a user input, a displayed graphical object, and modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved so that the moved graphical object is displayed under a portion of a second displayed graphical object.

Description

TECHNICAL FIELD

The present invention relates generally to computer graphics systems and more particularly to a method and apparatus for interlocking graphical objects.

BACKGROUND ART

In computer graphics systems, it is desired to represent two and three dimensional graphical pictures on a two dimensional display. Typically, such a picture is a construct or image that may be stored in memory as a set of polygons. To generate the picture on the display, the polygons are then rendered using processes that are typically computationally intensive. However, a portion of the picture to be represented may fall outside the field of vision provided by a window on the display or by the display itself. In such cases, it may be desirable to clip the picture and the polygons comprising the picture as the picture is being generated, thereby reducing computational requirements and increasing rendering speed.

A polygon is typically specified as a set of vertices P(0), P(1), . . . , P(n-2), P(n-1), where n is the number of vertices in the polygon. Each vertex P(i) is specified by its location V(i) in a suitable coordinate space and a function, referred to herein as a color factor, f(V(i)). A color factor is a function evaluated at each vertex that may be displayed later as a color (including a grayscale) variation (such as a light intensity, a thermal characteristic, a humidity factor, etc.). The color factor may be converted to a color and is useful in modelling (such as simple lighting modelling or more complex weather modelling).

Once the polygons are rendered, typical two dimensional graphics systems allow the user to pick and drag polygons to desired locations. A polygon is picked when the user selects that object, typically by positioning a cursor over the object and pressing a mouse button. The object is dragged by the user moving the cursor, typically by moving the mouse while continuing to press the mouse button. Typically, an object being dragged is shown in outline form during the dragging operation to reduce computational requirements of rendering the object as the object is moved. Once the user has completed dragging the object, the user may then drop the object, typically by releasing the mouse button. Prior art systems then render the polygon in the drop location. If there are any pre-existing objects that are also at the same location, then the dropped object is rendered as being on top of the pre-existing object. If the user desires the pre-existing object to be on top of the dropped object, then the user must pick the pre-existing object and then drop it without dragging the object anywhere. This results in the pre-existing object being placed on top of the just dragged object.

DISCLOSURE OF THE INVENTION

The present invention includes an apparatus for moving graphical objects including a display for displaying multiple graphical objects according to a display priority, apparatus for moving, responsive to a user input, a displayed graphical object, and apparatus for modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved so that the moved graphical object is displayed under a portion of a second displayed graphical object. In addition, the present invention includes a method for moving graphical objects including displaying multiple graphical objects according to a display priority on a display, moving, responsive to a user input, a displayed graphical object, and modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved so that the moved graphical object is displayed under a portion of a second displayed graphical object.

A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a diagram of a typical digital computer utilized by a preferred embodiment of the invention;

FIG. 2 is a block diagram illustrating the layers of code typically utilized by the host computer and graphics adapter to perform graphics functions;

FIG. 3 illustrates several polygons including convex and concave polygons being displayed;

FIGS. 4A-4D illustrate dragging object C of FIG. 3 across object A of FIG. 3; and

FIGS. 5A-5G are flowcharts illustrating dragging a graphical object according to a preferred embodiment of the invention.

BEST MODE FOR CARRYING OUT THE INVENTION

This disclosure describes an improved method and apparatus for interlocking objects, particularly in two dimensional environments. In the preferred embodiment, the user may drag a graphical object above, below, or both above and below (interlocking) another graphical object.

FIG. 1 is a block diagram of a typical digital computer 100 utilized by a preferred embodiment of the invention. The computer includes main processor(s) 110 coupled to a memory 120 and a hard disk 125 in computer box 105 with input device(s) 130 and output device(s) 140 attached. Main processor(s) 110 may include a single processor or multiple processors. Input device(s) 130 may include a keyboard, mouse, tablet or other types of input devices. Output device(s) 140 may include a text monitor, plotter or other types of output devices. Computer readable removable media 190, such as a magnetic diskette or a compact disc, may be inserted into an input/output device 180, such as a disk drive or a CD-ROM (compact disc - read only memory) drive. Data is read from or written to the removable media by the I/O device under the control of the I/O device controller 170. The I/O device controller communicates with the main processor through across bus 160. Main memory 120, hard disk 125 and removable media 190 are all referred to as memory for storing data for processing by main processor(s) 110.

The main processor may also be coupled to graphics output device(s) 150 such as a graphics display through a graphics adapter 200. Graphics adapter 200 receives instructions regarding graphics from main processor(s) 110 on bus 160. The graphics adapter then executes those instructions with graphics adapter processor(s) 220 coupled to a graphics adapter memory 230. The graphics processors in the graphics adapter then execute those instructions and updates frame buffer(s) 240 based on those instructions. Graphic processors 220 may also include specialized rendering hardware for rendering specific types of primitives. Frame buffer(s) 240 includes data for every pixel to be displayed on the graphics output device. A RAMDAC (random access memory digital-to-analog converter) 250 converts the digital data stored in the frame buffers into RGB signals to be provided to the graphics display 150 thereby rendering the desired graphics output from the main processor.

FIG. 2 is a block diagram illustrating the layers of code typically utilized by the host computer and graphics adapter to perform graphics functions. An operating system 300 such as UNIX provides the primary control of the host computer. Coupled to the operating system is an operating system kernel 310 which provides the hardware intensive tasks for the operating system. The operating system kernel communicates directly with the host computer microcode 320. The host computer microcode is the primary instruction set executed by the host computer processor. Coupled to the operating system 300 are graphics applications 330 and 332. This graphics application software can include software packages such as Silicon Graphic's GL, IBM's graPHIGS, MIT's PEX, etc. This software provides the primary functions of two dimensional or three dimensional graphics. Graphics applications 330 and 332 are coupled to graphics application API (application program interface) 340 and 342, respectively. The API provides many of the computationally intensive tasks for the graphics application and provides an interface between the application software and software closer to the graphics hardware such as a device driver for the graphics adapter. For example, API 340 and 342 may communicate with a GAI (graphics application interface) 350 and 352, respectively. The GAI provides an interface between the application API and a graphics adapter device driver 370. In some graphics systems, the API also performs the function of the GAI.

The graphics application, API, and GAI are considered by the operating system and the device driver to be a single process. That is, graphics applications 330 and 332, API 340 and 342, and GAI 350 and 352 are considered by operating system 300 and device driver 370 to be processes 360 and 362, respectively. The processes are identified by the operating system and the device driver by a process identifier (PID) that is assigned to the process by the operating system kernel. Processes 360 and 362 may use the same code that is being executed twice simultaneously, such as two executions of a program in two separate windows. The PID is used to distinguish the separate executions of the same code.

The device driver is a graphics kernel which is an extension of the operating system kernel 310. The graphics kernel communicates directly with microcode of the graphics adapter 380. In many graphics systems, the GAI, or the API if no GAI layer is used, may request direct access from the GAI or API to the adapter microcode by sending an initial request instruction to the device driver. In addition, many graphics systems also allow the adapter microcode to request direct access from the adapter microcode to the GAI or API if no GAI is used by sending an initial request instruction to the device driver. Both processes will hereinafter be referred to as direct memory access (DMA). DMA is typically used when transferring large blocks of data. DMA provides for a quicker transmission of data between the host computer and the adapter by eliminating the need to go through the display driver other than the initial request for the device driver to set up the DMA. In some cases, the adapter microcode utilizes context switching which allows the adapter microcode to replace the current attributes being utilized by the adapter microcode. Context switching is used when the adapter microcode is to receive an instruction from a graphics application that utilizes different attributes than the adapted microcode is currently using. The context switch is typically initiated by the device driver which recognizes the attribute changes.

Blocks 300-340 are software code layers that are typically independent of the type of graphics adapter being utilized. Blocks 350-380 are software code layers that are typically dependent upon the type of graphics adapter being utilized. For example, if a different graphics adapter were to be used by the graphics application software, then a new GAI, graphics kernel and adapter microcode would be needed. In addition, blocks 300-370 typically reside on and are executed by the host computer. However, the adapter microcode 380 typically resides on and is executed by the graphics adapter. However, in some cases, the adapter microcode is loaded into the graphics adapter by the host computer during initialization of the graphics adapter.

In typical graphics systems, the user instructs the graphics application to construct an image from a two or three dimensional model. The user first selects the location and type of light sources. The user then instructs the application software to build the desired model from a set of predefined or user defined objects. Each object may include one or more coplanar drawing primitives describing the object. For example, a set of drawing primitives such as many triangles may be used to define the surface of an object. The user then provides a perspective in a window to view the model, thereby defining the desired image. The application software then starts the rendering of the image from the model by sending the drawing primitives describing the objects to the adapter microcode through the API, the GAI, and then the device driver unless DMA is used. The adapter microcode then renders the image on the graphics display by clipping (i.e. not using) those drawing primitives not visible in the window and the adapter microcode breaks each remaining drawing primitive into visible pixels from the perspective given by the user. The pixels are then loaded into the frame buffer, often with the use of a depth buffer in the case of a three dimensional model. This step is very computationally intensive due to the number of drawing primitives, variables, and pixels involved. The resulting image stored in the frame buffer and displayed on the graphics display typically does not carry the original information such as which drawing primitive or object the pixel was derived from. As a result, the image may need to be rerendered in part or in whole if the window, the user perspective, the model, the lighting, etc. are modified.

In the preferred embodiment, the dragging technique could be utilized in many locations such as the adapter microcode which is close to the adapter frame buffer. This approach would also be relatively quick and fairly easy to implement. In addition, the dragging technique could be applied in the graphics application software wherein the rendered image is also stored in system memory either prior to the image being rendered or subsequently by the graphics adapter passing the data back up to the graphics application software. This approach would be much slower but would allow for utilization of this technique on preexisting graphics adapters. The dragging technique could also be implemented in hardware in the graphics adapter processor. This approach is extremely quick but may necessitate specialized hardware. This would allow for rapid clipping of primitives to be displayed by the graphics adapter. As would be obvious to one of ordinary skill in the art, the present technique would be applied in many other locations within the host computer or graphics adapter.

Most graphics objects can be described as polygons with a series of vertices. The polygon can be convex or concave. FIG. 3 illustrates several polygons including convex and concave polygons on a display 400. Polygons A and C are concave polygons while polygon B is a convex polygon. Each of the polygons is defined by a series of vertices which are interconnected by edges. A polygon is concave if there exists a vertex, such as vertex A1, that can be covered by the polygon when that vertex is removed from the polygon. For example, if vertex A1 was removed from polygon A then the new line running from vertices A2 to A4 would place previous vertex A1 on the interior of the polygon. A polygon may also be defined to be concave if the interior angle of the edges for any vertices is greater than 180 degrees. For example, in polygon B which is convex, all the interior angles at vertices are less than 180 degrees. However, the interior angle will at vertex A1 of polygon A is greater than 180 degrees.

Any concave polygon can be divided into a set of convex polygons by connecting each concave point to another vertex of the polygon such that each of the polygon parts is convex. With reference to polygon C of FIG. 3, the polygon can be divided into three convex polygons by dividing the polygon from vertex C4 to vertex C7 and from vertex C3 to vertex C8. In alternative approach to converting concave polygons to convex polygons is to divide each concave polygons into a series of triangles. With reference to polygon C of FIG. 3, the polygon C could also be divided from vertex C4 to vertex C6 and from vertex C3 to vertex C1 and from vertex C3 to vertex C7. In addition, all polygons could be broken into a set of triangles without determining whether the polygon is concave or convex. This would insure that all concave polygons are divided into a set of convex polygons.

In the preferred embodiment, when an object is dragged over another object, the dragged object can either dragged on top of the stationary object, below the stationary object, or some combination of above and below the stationary object called an interlock.

FIGS. 4A-4D illustrate dragging object C of FIG. 3 across object A of FIG. 3. FIG. 4A illustrates object C colliding with object A at vertex C7. At this point, in the preferred embodiment of the invention, the user designates whether object C would be dragged under or over object A. In the present example, the user selects object C to be dragged under object A for this collision. FIG. 4B illustrates object C being dragged under object A until a second point, vertex C2, collides with object A. At this point, according to the preferred embodiment of the invention, the user selects whether this part of object C will be dragged under or over object A. In the present example, the user selects that this part of object C will pass over object A. FIG. 4C illustrates objects A and C where a portion of object A overlays a portion of object C and another portion of object C overlays a portion of object A. FIG. 4D illustrates an interlock condition wherein object C can no longer be dragged upward. That is, given that one portion of object C overlays a portion of object A and another portion of object C underlays another portion of object A, any further dragging upward of object C will either require that object A or object C be sliced. In the preferred embodiment of the invention, object C will be prevented from being dragged upward to maintain the integrity of each object.

FIGS. 5A-5G are flowcharts illustrating dragging a graphical object according to a preferred embodiment of the invention. This flowchart assumes the user is using a mouse with buttons to pick and drag a desired graphical object. However, other alternative methods of picking and dragging objects would be apparent to those of ordinary skill in the art. In addition, graphical objects may be composed of several parts to handle the case where those graphical objects are concave and have been split into several convex parts, or the case where those graphical objects are a collection of several graphical objects grouped together to be dragged as a single graphical object. In the present example, each part of each object has an ABOVE.sub.-- LIST to indicate which parts of other objects are above that part and a BELOW.sub.-- LIST to indicate which parts of other objects are below that part.

FIG. 5A illustrates the initialization steps taken when an object is first picked in anticipation of dragging the object by the user and is preferably called when a mouse button is pressed. In step 500, the mouse focus is locked to maintain a pick on the object pointed to, the current position of the mouse is obtained to compute the position of the object outline as the object is dragged, the drawing mode is set to XOR (which will cause the object to be erased the second it is drawn in the same location) and the color is also set for showing a colored outline of the object as it is dragged. In step 510, a routine DRAW.sub.-- XOR.sub.-- FRAME is called to draw the XOR frame of the object prior to the object being dragged. The DRAW.sub.-- XOR.sub.-- FRAME routine is described in greater detail below. Pseudocode for FIG. 5A is provided in TABLE 1.

TABLE 1______________________________________Initialize Dragging Operation______________________________________METHOD MOUSE.sub.-- BUTTON.sub.-- PRESSED:LOCK MOUSE FOCUS;GET THE CURRENT MOUSE POSITION;SET THE DRAWING MODE TO XOR MODE;SET THE XOR MODE DRAWING COLOR;CALL (DRAW.sub.-- XOR.sub.-- FRAME) TO DRAW THEINITIAL XOR FRAME BEFORE DRAGGING;ENDMETHOD.______________________________________

FIG. 5B illustrates the steps taken when the user starts to drag the object by moving the mouse while the mouse button is pressed. In a first step 520, the new position of the mouse is obtained. In a second step 530, routine DETECT.sub.-- INTERSECT is called to determine whether the movement of the object has caused it to intersect or interlock with another object. This condition is tested in step 540. If an interlock condition has occurred, then the user may not drag the object any further and the drag routine is exited. In an alternative embodiment, the interlocked object may be grouped with the dragged object such that both objects are dragged together. If an interlock condition has not occurred, then processing continues to step 550. In steps 550 and 560, the XOR frame of the object is erased from the old position and then redrawn in the new position. In step 570, the old mouse position is set equal to the new mouse position. Pseudocode for FIG. 5B is provided in TABLE 2.

TABLE 2______________________________________Drag the Graphical Obiect______________________________________METHOD MOUSE.sub.-- MOVED:GET THE NEW MOUSE POSITION;CALL (DETECT.sub.-- INTERSECT);IF (INTERLOCK = FALSE) THEN:CALL (DRAW.sub.-- XOR.sub.-- FRAME) TO ERASE THE OLDXOR FRAME AT THE OLD MOUSE POSITION;CALL (DRAW.sub.-- XOR.sub.-- FRAME) TO DRAW THE NEWXOR FRAME AT THE NEW MOUSE POSITION;SET OLD MOUSE POSITION = NEW MOUSEPOSITION;ENDIF;ENDMETHOD.______________________________________

FIG. 5C illustrates the steps taken to determine whether the dragged object or a part of the dragged object has intersected a new object or part of an object. In a first step 600, OBJECT.sub.-- X is set to the first part of the dragged object (for the cases where the dragged object is a concave object split into multiple convex objects). In step 610, OBJECT.sub.-- Y is set to the first part of the first object in the window. In step 620, it is determined whether the two objects intersect for the first time. This can be determined by determining whether any of the edges of the objects intersect and then checking the ABOVE.sub.-- LIST and BELOW.sub.-- LIST of each object to see if a prior intersection has occurred. If step 620 is false, then processing continues to step 650 described below. If step 620 is true, then in step 630 it is determined whether the edges of intersection are an interior edge of either OBJECT.sub.-- X or OBJECT.sub.-- Y. If yes, then in step 635 the ABOVE.sub.-- LIST and BELOW.sub.-- LIST of each object is set to correspond to the ABOVE.sub.-- LIST or BELOW.sub.-- LIST of a corresponding part sharing the interior edge. That is, if OBJECT.sub.-- X is intersecting OBJECT.sub.-- Y for the first time at an interior edge of OBJECT.sub.-- Y, then OBJECT.sub.-- X must have previously intersected the part that shares the interior edge with OBJECT.sub.-- Y. IF OBJECT.sub.-- X is listed as below the other part that shares the interior edge, then OBJECT.sub.-- X should also be below OBJECT.sub.-- Y. Once step 635 is completed, processing continues to step 650 described below. If step 630 is false, then in step 640 it is determined whether the user is pressing the ALT key to indicate that OBJECT.sub.-- X (the dragged object) should pass under OBJECT.sub.-- Y. Of course, alternative embodiments could use other methods to indicate whether the dragged object should pass under or over other objects. If step 640 is false, then in step 645, OBJECT.sub.-- X is listed in the ABOVE.sub.-- LIST of OBJECT.sub.-- Y and OBJECT.sub.-- Y is listed in the BELOW.sub.-- LIST of OBJECT.sub.-- X. If step 640 is true, then in step 647, OBJECT.sub.-- X is listed in the BELOW.sub.-- LIST of OBJECT.sub.-- Y and OBJECT.sub.-- Y is listed in the ABOVE.sub.-- LIST of OBJECT.sub.-- X. In either case, processing continues to step 650. In 650, OBJECT.sub.-- Y is set to the next part of an object in the window. In step 655, it is determined whether the last part of an object in the window has been processed. If not, then processing returns to step 620. If so, then in step 660, OBJECT.sub.-- X is set to the next part of the dragged object. In step 665, all the entries of the previous OBJECT.sub.-- X ABOVE.sub.-- LIST and BELOW.sub.-- LIST are checked to see whether all the other parts listed still intersect. This could be easily checked by flagging every entry in the lists during the above described steps 620-650. If non-intersecting entries exist, then those entries should be erased in all lists according to the preferred embodiment. This will allow the user to initially specify that a dragged object is over a second object, withdraw the dragged object from intersecting the second object so that the entries in the lists of both objects are erased, then allowing the user to drag the dragged object under the second object. In step 670, it is determined whether all the parts of OBJECT.sub.-- X have been processed. If not, then processing returns to step 610. If so, the routine DETECT.sub.-- INTERLOCK is called. The routine DETECT.sub.-- INTERLOCK routine is described in detail below. Pseudocode for FIG. 5C is provided in TABLE 3.

TABLE 3______________________________________Detect Intersect Condition______________________________________METHOD DETECT.sub.-- INTERSECT:SET OBJECT.sub.-- X = FIRST PART OF THE DRAGGEDOBJECT;REPEAT.sub.-- START (FOR ALL PARTS OF THE DRAGGEDOBJECT):SET OBJECT.sub.-- Y = FIRST PART OF FIRST OBJECT INTHE WINDOWREPEAT.sub.-- START (FOR ALL PARTS OF THEWINDOW OBJECTS):IF (ANY EDGE OF OBJECT.sub.-- X INTERSECTS ANYEDGE OFOBJECT.sub.-- Y FOR THE FIRST TIME) THEN:IF (THE INTERSECTING EDGE IS AN INTERIOREDGEOF EITHER OBJECT.sub.-- X OR OBJECT.sub.-- Y)THEN:SET ABOVE.sub.-- LIST AND BELOW.sub.-- LIST OFOBJECT.sub.-- X AND OBJECT.sub.-- Y TO BE EQUAL TO THE PART OF OBJECT.sub.-- X OR OBJECT.sub.-- Y THAT SHARES THE COMMON INTERIOR EDGE;ELSE;IF (ALT KEY IS PRESSED) THEN:ADD OBJECT.sub.-- Y TO THE BELOW.sub.-- LISTOF OBJECT.sub.-- X;ADD OBJECT.sub.-- X TO THE ABOVE.sub.-- LISTOF OBJECT.sub.-- Y;ELSE:ADD OBJECT.sub.-- Y TO THE ABOVE.sub.-- LISTOF OBJECT.sub.-- X;ADD OBJECT.sub.-- X TO THE BELOW.sub.-- LISTOF OBJECT.sub.-- Y;ENDIF;ENDIF;ENDIF;SET OBJECT.sub.-- Y = NEXT PART OF THE NEXTOBJECT INTHE WINDOW;REPEAT.sub.-- UNTIL ALL THE PARTS OF ALL THEOBJECTS INTHE WINDOW HAVE BEEN PROCESSED;ERASE ALL ENTRIES IN DRAGGED OBJECTABOVE.sub.-- LIST ANDBELOW.sub.-- LIST AND CORRESPONDING ENTRIESIN WINDOW OBJECTS THAT NO LONGERINTERSECT EACH OTHER;SET OBJECT.sub.-- X = NEXT PART OF THE DRAGGEDOBJECT;REPEAT.sub.-- UNTIL ALL THE PARTS OF THEDRAGGED OBJECTHAVE BEEN PROCESSED;CALL (DETECT.sub.-- INTERLOCK)ENDMETHOD.______________________________________

FIG. 5D illustrates the steps taken to determine whether an interlock condition exists. In a first step 700, an INTERLOCK.sub.-- FLAG is set to false, OBJECT.sub.-- X is set as the dragged object, and OBJECT.sub.-- Y is set as the first object in the window. In step 705, VERTEX.sub.-- V is set as the first vertex of OBJECT.sub.-- Y. In step 710, it is determined whether OBJECT.sub.-- X has encountered VERTEX.sub.-- V of OBJECT.sub.-- Y for the first time or whether OBJECT.sub.-- Y has encountered VERTEX.sub.-- V of OBJECT.sub.-- X for the first time (all vertices of both OBJECT.sub.-- Y and OBJECT.sub.-- X are checked as VERTEX.sub.-- V). If not, then processing continues to step 730 described below. If step 710 is true, then in step 715 it is determined whether VERTEX.sub.-- V is in a concave portion of the object (OBJECT.sub.-- Y or OBJECT.sub.-- X) and whether an interlock condition occurs. An interlock condition occurs given VERTEX.sub.-- V is a vertex of OBJECT.sub.-- Y when OBJECT.sub.-- X is above one part of OBJECT.sub.-- Y and OBJECT.sub.-- X is also below a second part of OBJECT.sub.-- Y and both parts of OBJECT.sub.-- Y contain VERTEX.sub.-- V. An interlock condition occurs given VERTEX.sub.-- V is a vertex of OBJECT.sub.-- X when OBJECT.sub.-- Y is above one part of OBJECT.sub.-- X and OBJECT.sub.-- Y is also below a second part of OBJECT.sub.-- X and both parts of OBJECT.sub.-- X contain VERTEX.sub.-- V. If step 715 is false, then an interlock condition has not occurred and processing continues to step 730 described below. If step 715 is true, then an interlock condition has occurred and processing continues to step 720. In step 720, the INTERLOCK.sub.-- FLAG is set to TRUE and processing continues to step 730. In step 730, VERTEX.sub.-- V is set to the next vertex of OBJECT.sub.-- Y or OBJECT.sub.-- X (once all the vertices of OBJECT.sub.-- Y have been processed). In step 735, it is determined whether all the vertices of OBJECT.sub.-- Y and OBJECT.sub.-- X have been processed. If not, then processing returns to step 710. If so, then in step 740, OBJECT.sub.-- Y is set to the next object in the window. In step 745, it is determined whether all the objects in the window have been processed. If not, then processing returns to step 705. If so, then processing stops for this routine. Pseudocode for FIG. 5D is provided in TABLE 4.

TABLE 4______________________________________Detect Interlock Condition______________________________________METHOD DETECT.sub.-- INTERLOCK:SET INTERLOCK.sub.-- FLAG = FALSE;SET OBJECT.sub.-- X = THE DRAGGED OBJECT;SET OBJECT.sub.-- Y = THE FIRST OBJECT INTHE WINDOW;REPEAT.sub.-- START (FOR ALL OBJECTS):SET VERTEX.sub.-- V = THE FIRST VERTEX OFOBJECT.sub.-- Y;REPEAT.sub.-- START (FOR ALL OBJECT.sub.-- Y &X VERTICES):IF (OBJECT.sub.-- X ENCOUNTERS VERTEX.sub.-- V OFOBJECT.sub.-- Y FORTHE FIRST TIME OR OBJECT.sub.-- YENCOUNTERSVERTEX.sub.-- V OF OBJECT.sub.-- X FORTHE FIRST TIME)THEN:IF (VERTEX.sub.-- V IS IN A CONCAVE AREA ANDPART OFOBJECT.sub.-- Y IS BELOW OBJECT.sub.-- XAND IF ANOTHERPART OF OBJECT.sub.-- Y IS ABOVE OBJECT.sub.-- XAND BOTHPARTS OF OBJECT.sub.-- Y OR OBJECT.sub.-- XCONTAINVERTEX.sub.-- V) THEN:SET INTERLOCK.sub.-- FLAG = TRUE;ENDIF;ENDIF;SET VERTEX.sub.-- V = NEXT VERTEX OFOBJECT.sub.-- Y OROBJECT.sub.-- X;REPEAT.sub.-- UNTIL ALL THE VERTICES OFOBJECT.sub.-- Y ANDOBJECT.sub.-- X HAVE BEEN PROCESSED;SET OBJECT.sub.-- Y = NEXT OBJECT IN THE WINDOW;REPEAT.sub.-- UNTIL ALL THE OBJECTS IN THE WINDOWHAVE BEENPROCESSED;ENDMETHOD.______________________________________

FIG. 5E illustrates the termination steps taken when the user completes dragging the graphical object and is called when the mouse button is released. In step 800, the mouse focus is unlocked thereby releasing the pick of the object. In step 810, the routine DRAW.sub.-- XOR.sub.-- FRAME is called to erase the last XOR frame of the object at the current mouse position. In step 620, the drawing mode is set back to copy mode from XOR mode. In step 630, routine OBJECT.sub.-- REDISPLAY is called to redraw the object in full form at the final mouse position. The OBJECT.sub.-- REDISPLAY routine is described in greater detail below in reference to 5G. Pseudocode for FIG. 5E is provided in TABLE 5.

TABLE 5______________________________________TERMINATE DRAGGING OPERATION______________________________________METHOD MOUSE.sub.-- BUTTON.sub.-- RELEASED:UNLOCK THE MOUSE FOCUS;CALL (DRAW.sub.-- XOR.sub.-- FRAME) TO ERASE THELAST XOR FRAME ATTHE CURRENT MOUSE POSITION;SET THE DRAWING MODE TO COPY MODE;CALL (OBJECT.sub.-- REDISPLAY) TO REDISPLAYTHE DRAGGEDOBJECT.sub.-- X AT THE FINAL MOUSE POSITION;ENDMETHOD.______________________________________

FIG. 5F illustrates the steps taken to draw the dragged object and is called by the routines described above. In step 850, PART.sub.-- A is set to the first part of OBJECT.sub.-- X (this is to handle the case where OBJECT.sub.-- X is concave and has been split into several convex parts or OBJECT.sub.-- X is a collection of graphical objects). In step 860, OBJECT.sub.-- Y is set to the first object of the ABOVE.sub.-- LIST. In step 870, PART.sub.-- A is clipped by OBJECT.sub.-- Y and OBJECT.sub.-- Y is set to the next part of the ABOVE.sub.-- LIST. In step 875, it is determined whether all the parts of the top list have been processed. If not, then processing returns to step 870, else processing continues to step 880. In step 880, PART.sub.-- A is set to the next part of OBJECT.sub.-- X. In step 885, it is determined whether all the parts of OBJECT.sub.-- X have been processed. If not, then processing returns to step 860, else processing stops. Pseudocode for FIG. 5F is provided in TABLE 6.

TABLE 6______________________________________Draw Object XOR Frame______________________________________METHOD DRAW.sub.-- XOR.sub.-- FRAME:SET PART.sub.-- A = THE FIRST PART OF THE DRAGGEDOBJECT.sub.-- X;REPEAT.sub.-- START:SET OBJECT.sub.-- Y = THE FIRST PART OF THEABOVE.sub.-- LIST;REPEAT.sub.-- START:CLIP PART.sub.-- A BY OBJECT.sub.-- Y;SET OBJECT.sub.-- Y = THE NEXT PART OF THEABOVE.sub.-- LIST;REPEAT.sub.-- UNTIL ALL THE PARTS OF THEABOVE.sub.-- LIST HAVEBEEN PROCESSED;SET PART.sub.-- A = THE NEXT PART OF THEDRAGGED OBJECT.sub.-- X;REPEAT.sub.-- UNTIL ALL THE PARTS OF THEDRAGGED OBJECT.sub.-- XHAVE BEEN PROCESSED;ENDMETHOD.______________________________________

FIG. 5G illustrates the steps taken to redisplay a dragged object in a window and is called by the routines described above. In step 900, the dragged object is drawn and PART.sub.-- A is set as the first part of the dragged object. In step 910, the first entry of the ABOVE.sub.-- LIST of PART.sub.-- A is retrieved. In step 920, the object that contains the selected part listed in the ABOVE.sub.-- LIST of PART.sub.-- A is displayed. In addition, the next entry of the ABOVE.sub.-- LIST of PART.sub.-- A is retrieved. In step 925, it is determined whether all the entries in the ABOVE.sub.-- LIST of PART.sub.-- A have been processed. If not, then processing returns to step 920. If so, then in step 930, PART.sub.-- A is set to the next part of the dragged object. In step 935, it is determined whether all parts of the dragged have been processed. If not, then processing returns to step 910. If so, then processing ends. Pseudocode for FIG. 5G is provided in TABLE 7.

TABLE 7______________________________________REDISPLAY OBJECT______________________________________METHOD OBJECT.sub.-- REDISPLAY:DRAW THE DRAGGED OBJECT;SET PART.sub.-- A = THE FIRST PART OF THEDRAGGED OBJECT;REPEAT.sub.-- START:START FROM THE FIRST PART OF THEABOVE.sub.-- LIST OFPART.sub.-- A;REPEAT.sub.-- START:DISPLAY THE OBJECT THAT CONTAINS THEPART IN THEABOVE.sub.-- LIST OF PART.sub.-- A;MOVE TO THE NEXT PART OF THEABOVE.sub.-- LIST OFPART.sub.-- A;REPEAT.sub.-- UNTIL ALL THE PARTS OF THEABOVE.sub.-- LIST OFPART.sub.-- A HAVE BEEN PROCESSED;SET PART.sub.-- A = THE NEXT PART OF THEDRAGGED OBJECT;REPEAT.sub.-- UNTIL ALL THE PARTS OF THE DRAGGEDOBJECT HAVEBEEN PROCESSED;ENDMETHOD.______________________________________

Although the present invention has been fully described above with reference to specific embodiments, other alternative embodiments will be apparent to those of ordinary skill in the art. Therefore, the above description should not be taken as limiting the scope of the present invention which is defined by the appended claims.

Claims

1. An apparatus for moving graphical objects comprising:

a display for displaying a plurality of graphical objects according to a display priority;

means for moving, responsive to a user input, a first displayed graphical object; and

means for modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved such that the moved graphical object is displayed under a first portion and above a second portion of a second displayed graphical object.

2. The apparatus of claim 1 further comprising means for computing whether the moved graphical object interlocks the second displayed graphical object.

3. The apparatus of claim 2 further comprising means for preventing said moved graphical object from being moved any further if the moved graphical object is computed to interlock the second displayed graphical object.

4. The apparatus of claim 2 further comprising means for grouping said second displayed graphical object with said moved graphical object so that both objects are moved together.

5. A data processing system comprising:

a display for displaying a plurality of graphical objects according to a display priority;

a memory for storing data,

a processor for processing said stored data, said processor including:

means for moving, responsive to a user input, a first displayed graphical object; and

means for modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved such that the moved graphical object is displayed under a first portion and above a second portion of a second displayed graphical object.

6. The data processing system of claim 5 wherein said processor further includes means for computing whether the moved graphical object interlocks the second displayed graphical object.

7. The data processing system of claim 6 wherein said processor further includes means for preventing said moved graphical object from being moved any further if the moved graphical object is computed to interlock the second displayed graphical object.

8. The data processing system of claim 6 wherein said processor further includes means for grouping said second displayed graphical object with said moved graphical object so that both objects are moved together.

9. A method for moving graphical objects comprising:

displaying a plurality of graphical objects according to a display priority on a display;

moving, responsive to a user input, a first displayed graphical object; and

modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved such that the moved graphical object is displayed under a first portion and above a second portion of a second displayed graphical object.

10. The method of claim 9 further comprising the step of computing whether the moved graphical object interlocks the second displayed graphical object.

11. The method of claim 10 further comprising the step of preventing said moved graphical object from being moved if the moved graphical object is computed to interlock the second displayed graphical object.

12. The method of claim 10 further comprising the step of grouping said second displayed graphical object with said moved graphical object so that both objects are moved together.

13. A computer program product for moving graphical objects comprising:

computer readable program code means for displaying a plurality of graphical objects according to a display priority on a display;

computer readable program code means for moving, responsive to a user input, a first displayed graphical object; and

computer readable program code means for modifying, responsive to a user input, a display priority of the moved graphical object as the graphical object is moved such that the moved graphical object is displayed under a first portion and above a second portion of a second displayed graphical object.

14. The computer program product of claim 13 further comprising computer readable program code means for computing whether the moved graphical object interlocks the second displayed graphical object.

15. The computer program product of claim 14 further comprising computer readable program code means for preventing said moved graphical object from being moved if the moved graphical object is computed to interlock the second displayed graphical object.

16. The computer program product of claim 14 further comprising computer readable program code means for grouping said second displayed graphical object with said moved graphical object so that both objects are moved together.