A method of operating a computer graphics system.

0001This invention relates to a method of operating a computer graphics system and particularly to locally programmed interactive graphics workstations in which a user selects a graphics primitive in the display image by means of positioning a "pick window" an area of the display screen active for picking.

0002In Graphics Computing systems that provide the pick window function, the position of the pick window is usually visually indicated to a user by means of a tracking cursor. Such systems have a display processor which processes a graphics program stored in a memory sometimes referred to as a display list buffer to generate a graphics image on the display screen of the system (see Fig 1). The graphics program stored in the display list buffer is produced by an application program running in the system, or workstation, or on a remote host computer.

0003This type of workstation architecture is well known in the literature (see, for instance, Foley and Van Dam's text, Fundamentals of Interactive Computer Graphics, pages 19-20 and 200-203). The IBM 5080, described in IBM publication GA23-2012-0 ("IBM 5080 Graphics System: Principles of Operation, 5085 Model 2"), serves as one specific example of such a display list programmed workstation providing a picking function.

0004A common problem which must be solved in the user-interface of such a workstation is how to give the user the ability to identify which graphics primitive he wishes to select if more than one primitive intersects the pick window.

0005European Patent Application 0 203 324 discloses a technique whereby as the user moves a pointing cursor around an image which has been drawn on a display screen, the point on graphics primitives nearest to the pointing cursor is highlighted. This shows the user which primitive would be selected if a select button were pressed.

0006The methods for solving the identification problem can be divided into two categories, those in which the "visual feedback" function is provided by the workstation independent of the application program, and those in which the application program uses the features of the workstation to perform the "visual feedback" function. Each of these categories will now be presented, along with a discussion of their advantages and disadvantages:

1. Application-provided visual feedback" approaches:

0007One such approach available to applications for solving the problem posed by multiple pickable primitives in the pick window is for the application to give the user the ability to magnify the image when necessary. By magnifying the image, the pick window can be positioned in such a way that only the desired primitive intersects the pick window. Once the picking action has been performed on the magnified image, the user may then "demagnify" the image back to its original size. This approach, however, has the drawback that the user's productivity is reduced by the additional steps he must take to accomplish the magnification/demagnification processes.

0008An alternative to the "magnify-demagnify" approach is for the application to provide a selective highlight or display of primitives (or high-level structures) that pass through the pick window. In order to do this, the application must take special action when it detects that a primitive that it just drew caused a pick. Currently available graphics systems, such as the IBM 5080, offer applications the choice of handling pick events at the remote host or the workstation's general purpose processor, or locally in the display list program itself. Each of these picking modes will now be described. <ul id="ul0001" list-style="none"><li>a. Remote pick processing - In the case where picks are handled at the host or workstation processor, any time a pickable primitive is drawn in the pick window the display processor immediately interrupts the host or workstation processor with the data for the pickable primitive, and suspends operation until it receives a command back from the processor. Processing of the pickable primitive is then done at the remote host instead of by the display processor. The advantage of this picking mode that that control is automatically given to the processing unit that handles the pick event whenever the display processor detects that a primitive was drawn in the pick window; no overhead is added to the display list program to test whether a pick window intersection occurred. Since such a test is needed after each time a primitive is drawn this is a significant feature. A disadvantage of this picking mode is that it incurs the performance penalties arising from communication between the display processor and the host or workstation processor when a pick intersection occurs, and the increased likelihood that the state of the interactive devices may change between the time of the pick window intersection and the time that the host or workstation processor responds.</li><li>b. Local pick processing - In the "local" picking mode, any time a pickable primitive is drawn in the pick window the workstation saves the pick data for that primitive in a local save area, and sets an indicator for the display program to know that a pick window intersection occurred. After this, execution continues at the next graphics instruction. The display program can add instructions after each primitive is drawn to test for the occurrence of a pick window intersection, and take appropriate action to perform some sort of visual feedback if a pick window intersection did occur. This picking mode has the advantage that it permits local (display processor) processing of pickable primitives, thus avoiding the performance penalties of communicating with a remote host or workstation processor. However, "local" picking mode of current graphic workstations has the disadvantage that additional graphics instructions must be inserted at many places in the display program, thus reducing the application's performance and increasing its program storage requirements.</li></ul>

0009Due to the disadvantages listed above for the remote and local picking modes, many graphics applications to date have offered the "magnify-pick-demagnify" technique instead of providing a true high-level visual feedback function. Unfortunately, the brunt of the selection process is then put on the user of the graphics application.

2. Workstation-provided visual feedback approaches:

0010In these approaches, the workstation itself keeps track of those primitives that intersect the pick window, and displays or highlights them one at a time in response to some signal (such as the depression of a keyboard button) issued by the user. This is an improvement over the application-provided visual feedback approach in that the user no longer needs to magnify/demagnify the image. However, this approach has the drawback that the set of display or highlight functions available to the application is limited to those that are implemented in the hardware of the workstation. These are usually limited to simpler building-block primitives (such as lines) instead of the aggregate graphic structures an application allows its users to select. Thus, an application is often unable to visually identify the complete structure which represents the pickable entity, a drawback which poses ambiguity problems for the user of the application. With the workstation-provided visual feedback approach, the application is not given the ability to implement the visual feedback requirements of its own unique user-interface.

0011Accordingly the invention provides a method of operating a computer graphics system having a processor that executes sets of microcoded instructions to generate data corresponding to basic graphic elements, called primitives, in response to a main list of application display instructions, said data being used to generate a display of those primitives, and that includes means for defining a display region, called a pick window, for identifying for selection primitives that intersect said pick window in said display, said method enhancing the selectability of pickable primitives that intersect said pick window, comprising the steps of providing a further list of application display instructions, called a selection subroutine, for saving data pertaining to primitives that intersect with the pick window for the purpose of effecting subsequent modification of the display area to facilitate selection of such intersecting primitives; providing further microcoded instructions to test whether a set of microcoded instructions previously executed for generating data corresponding to a primitive caused a pickable primitive to be drawn in said pick window; if the previous step determines that a pickable primitive has been drawn in the pick window, suspending execution of the main display list, and executing the selection subroutine; and then resuming execution of the main list of application display instructions at a selected instruction therein.

0012In order that the invention may be fully understood a preferred embodiment will now be described with reference to the accompanying drawings, in which:-

0013Fig. 1 is a block diagram of a graphics workstation in which the method of the present invention is applied.

0014Fig. 2 is a flowchart of a first part of the preferred embodiment of the present invention.

0015Fig. 3 is a flowchart of a second part of the preferred embodiment of the present invention.

0016Fig. 4 is a flowchart showing typical steps in a subroutine according to the preferred embodiment of the present invention.

0017The preferred embodiment of the present invention, including specific structural and functional details, are disclosed herein. These specifics are merely representative, and in that regard, provide a basis for the claims herein which define the scope of the invention. It is not intended that the specifics be construed as a limitation of the principles set forth in the claims.

0018In the preferred embodiment of this invention, the workstation's display processor provides application control of the pre-selection process by performing the following steps after completion of each graphics instruction: <ul id="ul0002" list-style="none"><li>1. Testing whether or not the instruction just completed caused a pickable primitive to be drawn in the pick window region;</li><li>2. If the operation just completed caused a pickable primitive to be drawn in the pick window, the following steps are performed: <ul id="ul0003" list-style="none"><li>a. The address of the order after the operation that caused a pickable primitive to be drawn in the pick window is pushed onto the application's hardware stack (this enables the application's selection subroutine to return to the visualization display list program at the point from which it left when the subroutine completes execution) ;</li><li>b. Normal display list execution of the application's visualization display list program is suspended, and the hardware begins display list execution at the address of the selection subroutine (n.b., the selection subroutine must not draw a pickable primitive in the pick window, in order to avoid infinite recursion).</li></ul></li><li>3. If the instruction just completed did not cause a pickable primitive to be drawn in the pick window, workstation execution continues with the next graphics instruction.</li></ul>

0019The workstation's display processor performs the following steps whenever a pickable primitive intersects the pick window: <ul id="ul0004" list-style="none"><li>1. Saving the data relevant to the primitive just drawn in a storage area for potential use at a later time;</li><li>2. Setting a flag to indicate that a pickable primitive intersected the pick window.</li></ul>

0020Figs. 2 and 3 are detailed flowcharts of how this improved method for handling potentially picked primitives would typically be implemented. Fig. 2 shows the steps by which the exit to the application-provided display list subroutine is effected, while Fig. 3 shows the steps that are performed any time a primitive intersecting the pick window is drawn. These two processes communicate with each other by means of a flag which indicates whether or not the application-provided display list subroutine is to be given control at the end of the current graphics instruction. This "branch to the application-provided subroutine" flag is tested and reset by the process in Fig. 2, and set by the process in Fig. 3.

0021The following implementation points must be observed to make the application interface of the preferred embodiment work well: <ul id="ul0005" list-style="none"><li>1. In order to avoid infinite recursion, the "pick window intersection" subroutine provided by the application must not draw a pickable primitive in the pick window.</li><li>2. In order to provide meaningful data to the visualization display program, the workstation hardware must defer transferring control to the "pick window intersection" subroutine until an "atomic" drawing operation completes (e.g., during an area fill operation, the workstation hardware must complete the fill process prior to transferring control to the application's selection routine, even if the area fill boundary intersected the pick window; this is because the area fill primitive is the item of interest, not the boundary of the area fill).</li></ul>

0022According to the present invention, the application-provided display list subroutine can immediately perform the display function programmed into the application with respect to the primitive that intersected the pick window, or it can save any data needed to perform the application's unique display or highlight functions at a later point in the image generation cycle. When the subroutine is finished, it executes a "POP" instruction to cause workstation execution to resume at the address placed on the stack prior to branching to the application-provided subroutine. In this way, each application can "customize" the workstation to achieve the user-interface it wishes to provide.

0023For example, if the image is that of an automobile, and a vector in the bumper passes through the pick window, the application may be programmed to highlight the vector, the bumper, or the entire car; or it can be programmed to erase the vector, the bumper, or the entire car; or any number of other combinations of useful visual effects. As another example, under application control, a user of the system could "step through" a pick window in a way which permits successive display of the structure which would be selected if the user were to signal that to the system. Since the application controls this process, it can guarantee that the item indicated to be selected will be the item that will actually be selected. Thus the user of the workstation may clearly see what item the application will select prior to the actual selection. Furthermore, the application may be programmed to permit the user to make his "final choice" at any moment during the "step through" process. All of the above-described application "customized" display functions are readily programmable to those having ordinary skill in the art.

0024The flowchart in Fig. 4 shows the typical steps the application-provided display list subroutine performs in handling primitives that intersect the pick window. Such a subroutine has total flexibility as to what to do when it is given control by the workstation. It can immediately use the data provided by the workstation to change the display, it can save the data in a table for use at a later time, or it can not use the data at all. When the subroutine is finished, it can return to the graphics program at the point from which it was entered, or it can be programmed to branch somewhere else and not return at all.

0025The data which is saved in this part of the preferred embodiment of the present invention depends upon the particular architecture of the graphics computer system involved. In a typical computer graphics system architecture, such as the IBM 5080 workstation, the main application program is provided as a listing of commands, and data corresponding to the primitives to be drawn in accordance with the commands. These primitives may be, for example, vectors. If data is to be saved for a vector, for example, in order to permit the application to readily provide the desired visual enhancement, the data saved is the x, y, and z of the end point of the vector, the address of the graphics instruction in the display program listing for drawing the vector, the address of the vector in the data list of the graphics instruction, and the segment name, that is, the name of the overall structure that the primitive is part of. The reason for saving the address of the primitive in the data list is that according to typical graphics architectures, a given graphics instruction may relate to a number of geometric primitives, such as a string of vectors. In order to permit the application subroutine to identify which vector primitive associated with the given graphics instruction is the one which intersects the pick window, the address of the instruction associated with that vector primitive is provided. The segment name permits the application to construct the overall geometric element of which the primitive is a part, for example, for visual enhancement of the overall geometric structure. The rather considerable flexibility afforded by this saving of data will be readily apparent to those skilled in this art.