JPH09504894A - Graphic state processing - Google Patents

Abstract

  (57) [Summary] A method and system for graphic state processing in which a graphic state object separate from the graphic contains state information. State objects can be accessed while not drawing. Objects consist of substates that represent a particular graphics processing state. The graphic only needs to send the graphic hierarchy, and the graphic state object automatically undertakes and handles sending the graphic state to the rendering device. A graphic state object is an entity separate from the graphic being drawn.

Description

DETAILED DESCRIPTION OF THE INVENTION Graphic State Handling Copyright notices A portion of this patent application contains material which is subject to copyright protection. The copyright owner has no objection if the copy is either in the patent document or the disclosure of the patent, such as would appear in the Patent and Trademark Office patent file or records, but in any other case, All copyrights are reserved. CROSS-REFERENCE This patent application is related to a patent application called OBJECT ORIENTED GRAPHIC SYSTEM filed on November 3, 1993, and is assigned to Taligent. The disclosure of which is incorporated herein by reference. FIELD OF THE INVENTION The present invention relates generally to improvements in computer systems, and more particularly to systems and methods for graphic state processing. BACKGROUND OF THE INVENTION In previous graphics architectures, a graphic typically stored its state (eg, color, transfer mode, clip area, etc.) privately. When asked to draw, the graphic procedurally copies these state variables into the GrafPort, which are accessed by the rendering code. Therefore, the state of this graphic is available only during this explicit drawing operation. This is a limitation that graphic systems, not object-oriented, cannot do. Another problem with prior art graphics architectures is forcing a graphics hierarchy within a graphic object because that object interacts with that object while it is drawing. is there. SUMMARY OF THE INVENTION Therefore, a first object of the present invention is to provide a system and method for processing graphic states. It is a further object of the present invention to provide a system and method that provides access to a graphic state other than the graphic that uses the graphic state. These and other objects of the invention are to provide a method and system having a graphics state object used by a graphic to render that graphic. Graphic state objects may also include the ability to establish relationships with rendering devices and associated caches. In addition, the state object contains a number of sub-states. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram illustrating a typical hardware configuration of a computer according to the present invention. FIG. 2 is a diagram showing the entire structure of TGrafState. FIG. 3 is a diagram showing a TgrafPort to which a method for accessing a device and a device cache is added. FIG. 4 is a diagram showing a TGrafPort that allows a graphic object to "dump" its contents into a TGrafDevice object as appropriate. FIG. 5 is a diagram showing a simple hierarchical graphic. FIG. 6 is a diagram showing an object in the Draw call of TPolygon. FIG. 7 is a diagram showing a transient hierarchy. FIG. 8 is a diagram showing a TRootGrafPort class (class) including default values for each sub-state. FIG. 9 is a diagram showing a TLinkedBundlePort class that plays a role of concatenating a “parent” TGrafPort object and a TGrafBundle object. FIG. 10 is a diagram showing the relationship of the TSimpleMatrixState class. FIG. 11 is a diagram showing a relationship between TClipState subclasses. FIG. 12 is a diagram showing relationships established for TMatrix3DState. FIG. 13 is a diagram showing an example of a graphic hierarchy. FIG. 14 is a diagram of MGraphic. FIG. 15 is a flow chart showing an example of what happens when a call to TMyGroup :: Draw is made. DETAILED DESCRIPTION OF THE INVENTION Detailed embodiments of the present invention are disclosed herein. However, it should be understood that the disclosed embodiments are merely illustrative of the invention and may be embodied in various forms. Therefore, the details disclosed herein should not be construed as limiting, but merely as a basis for the claims, as a basis for teaching those skilled in the art how to make and / or use the invention. Be interpreted. The history of object-oriented programming and the development of frameworks are fully established in the literature. C ++ and Smalltalk are well documented and will not be described in detail here. Similarly, the properties of objects, such as encapsulation, polymorphism, inheritance, are well explained in the literature and patents. For a good overview of object-oriented systems, readers should refer to Grady Booch's “Object Oriented Design With Applications”. Many object-oriented systems are designed to run on the underlying operating system that performs the basic I / O, but this system provides system-level support for special features. It is used to The preferred implementation of the invention is under an operating system residing on a personal computer, such as IBM's PS / 2 (R) or Apple (R) Macintosh (R). It is the execution in. A typical hardware environment is depicted in Figure 1. FIG. 1 is a diagram depicting a typical hardware configuration of a computer according to the main invention, showing a central processing unit 100, for example a normal microprocessor, and many other units interconnected via a system bus 132. have. The computer shown in FIG. 1 has a read only memory (ROM) 104, a random access memory (RAM) 106, peripherals, such as other I / O peripherals represented by disk units 108 and 110. An input / output adapter 112 that connects the device to the system bus 132, a keyboard 130, a mouse 126, a speaker 122, a microphone 124, and / or other user interface device, such as a touch screen device (shown) connected to the bus. Communication interface 116 that connects the workstation to the data processing network represented by the user interface adapters 128, 114 that connect the (not) to the bus. A display adapter 120 connects the bus to the display device 118. The workstation has an operating system residing on it, for example the Apple System / 7® operating system. Definition Graphic State-All graphical state variables (sometimes called attributes) needed to draw a geometry, such as paint and transfer mode. ), Pen geometry, matrix, clip area, etc. Graphic Hierarchy-A hierarchical arrangement of graphical primitives in which graphic states, such as coordinate system and clipping information, can be inherited from a parent graphic to a child graphic. GrafPort-A container for a complete set of graphic states, devices, and device caches. The disclosed graphics state processing system achieves many goals of increasing the overall efficiency of graphics processing applications. One of those goals is to support an abstract base class that represents a collection of all graphical states, and a hierarchical behavior of states (concatenation: Support). Subclasses provide specific implementations for storage and concatenation of state variables. Another purpose is to require that the connection of the child graphic state to the parent state must be isolated at the child. The parent's condition should not be affected by the concatenation. Furthermore, the child has the final say in determining the final value of a variable. Therefore, the parent cannot indicate the value of a variable. The goal is also that the graphic state can easily communicate with the TGrafDevice object. Yet another goal is to support a framework that allows graphics state to be accessed outside the context of the graphics Draw call. For example, a sprite would need access to a graphic state object to draw into a view. Another goal is to not bake any assumptions about the graphic hierarchy into the TGrafDevide class. The graphic hierarchy is naturally realized within the graphic itself. Therefore, no special design can be imposed on the hierarchy by TGarfDevice. Finally, another goal is to make all device-dependent data types private to the device. For example, all clipping is specified by TGAreas, not the area. As explained in the background of the invention, in previous graphic architectures, the graphic typically privately stores its state (eg, color, transfer mode, clip area, etc.). When drawing is requested, the graphic procedurally copies these state variables into the GrafPort and is accessed by the rendering code. Therefore, the graphics state is only available during this explicit drawing operation. The system provides a framework for graphics to store their state. The architecture supported by this framework allows clients to access graphics state outside the context of a "draw" function. The set of graphic states can be represented by a single object instead of a series of codes. This is the goal of the TGrafP ort class. An abstract class defines the interface for accessing state variables. The concrete subclass defines the actual storage and concatenation behavior of the state variables. The old way is And the new way is It is. TGrafState and TGrafPort FIG. 2 is a diagram showing the overall structure of TGrafState. This structure groups all graphic states into 6 different groups and then puts them together in a single class called TGrafState200. The six “sub-states” 202 are TA ttributeState (set of attributes that determine the appearance of the graphic), two TMatrixStates (2D view and model coordinate system), TClipState (2D clipping information), TSceneState ( 3D camera and light), TMatrix3DState (3D model coordinate system). The T GrafState object 200 is used by classes that need access to all graphic states. Moreover, due to the abstract design of the TGrafState class, the child graphic state is linked to its parent state without actually changing the parent state. It should be noted that FIG. 2 is not exhaustive. The six sub-states shown here can be larger or smaller than six depending on the desired design. Moreover, the elements that make up the six substates are not exhaustive. For example, the attributes can virtually include any of the graphic attributes known in graphic processing. Also shown in FIG. 2 are exemplary elements 204 of the six sub-states 202 outlined above. In particular, GetAttributeState has GetDrawOperation, GetFill Paint, GetFramePaint and GetAntialiasing; GetViewMatrixState has Get Matrix; GetModelMatrix has GetMatrix; GetClipState has GetClipArea; GetSceneState has CreateLightIterator and these substates with Elements are merely examples, and many include more than those shown and described herein. The TGrafPort class is a subclass of TGrafState. As shown in FIG. 3, TGrafPort adds method 302 to access devices and device caches. GetDevice returns a pointer to the device where the rendering is done. GetCache returns a pointer to the cache used by devices that cache device-dependent objects. TGrafPort also contains 6 substates. The main purpose of subclassing the TGrafPort 300, including the six sub-states, is to define how graphics state, devices, and storage of device caches are tied together. Substates help divide state variables into commonly used groups. Simpler, flatter groups of state variables are not flexible enough to allow customization of state concatenation for a subset of state variables. For example, simple graphics typically only require TGrafBundle, a useful TAttributeStat e subclass. More complex graphic objects require a matrix and possibly a clip area. See the substates section for more information on these classes. Graphics classes such as MGraphic must describe themselves to TGrafDevide by a basic set of geometries, and each geometry must have a set of TGrafState objects associated with it (not necessarily unique). It doesn't have to be). As shown in FIG. 4, TGrafPort 402 allows graphic object 400 to "dump" its contents into a TGrafDevice object as appropriate. This is accomplished by supplying a set of Draw functions to the TGrafPort class, which reflects the set of Render functions provided by the TGrafDevice class. Each Draw function takes a geometry and passes it and the port's graphic state 404 to the appropriate Render call of device 408. For convenience, the overriding bundle and model matrix can also be passed at 404. The TGrafPort class is shown below. These are 2D Draw calls. They exist for convenience only. They call the corresponding TGrafDevide :: Render calls to pass the graphics state and device cache. The purpose of multiple, disjoint calls (as opposed to polymorphic single calls) is that only small, well-defined sets of basic 2D geometries are supported by the graphics device. This is to enforce the rule. These are 2DDraw calls that take an additional bundle and model matrix. They exist for convenience only due to certain special conditions. They call the corresponding TGrafDevide :: Render calls to pass the graphics state and device cache. Before the appropriate TGrafDevice :: Render function is called, the bundle and model matrix are bound to the state, as shown at 404 in the TGrafPort object. The purpose of the bundles and optional matrix is to facilitate the coupling of typically changing states from geometry to geometry. However, since this concatenation occurs each time it is called, their use is discouraged when bundles or matrices are shared by multiple geometries. These are 3D Draw calls. They exist only for convenience. They make the corresponding TGrafDevice :: Render calls and pass the graphics state and device cache. Similar to 2D calls, the purpose of many disjoint calls is to enforce the rule that only a small, well-defined set of basic 3D geometries is supported by a graphics device. . These are 3DDraw calls that take an additional bundle and a 3D model matrix. They exist for convenience only due to certain special conditions. They make the corresponding TGrafDevice :: Render call and pass the graphics state and device cache 406. Although cache 406 is shown as residing in device 408, this is for illustration purposes only. The cache 406 may actually be anywhere memory is provided, may be memory separate from the device 408, or may be directly related to where a particular graphics rendering is being performed. Not in another device. Before the appropriate TGrafDevice :: Render function is called, the bundle and model matrix is bound to the state, as shown at 404 in the TGrafPort object. The purpose of the bundles and optional matrix is to facilitate the coupling of typically changing states from geometry to geometry. However, since this concatenation occurs each time it is called, their use is discouraged when bundles or matrices are shared between multiple geometries. A. Device Cache Since device cache 406 can potentially be large objects, care must be taken to ensure that they do not inadvertently propagate through the system. There are two approaches to the default behavior. 1. Each GrafPort can have its own device cache, but it will be expensive. There will be too many caches to hang around. This is not the desired default behavior. 2. Each TGrafPort creates its own cache if it is not given by the parent. By default, this means that only the GrafPort at the top of each graphics hierarchy can have a cache. This is probably the default behavior that is acceptable. If the same root GrafPort is used as a bunch of layers, this layer will automatically share the cache at the root GrafPort. If a cache is required for each GrafPort, a GrafPort subclass will be written to achieve that. In some cases it is desirable to override the default cache behavior. The view may want so. In the old view system, each view cached a device-dependent area. Region generation was very expensive, so it was a good optimization. In the present system, views can maintain their own device cache (which caches regions like other device-dependent objects). B. Graphic State Concatenation FIG. 5 provides a simple hierarchical graphic. The graphic of FIG. 5 consists of polygons 502 and ellipses 506 in group 500. Each graphic in the hierarchy can store any subset of the graphic states. For example, a polygon and an ellipse have TGrafBundles 504 and 508 respectively, but TGroup does not store any graphic state. This seems quite straightforward until hierarchical states, eg matrices, are considered. To create an accurate, local-to-global matrix, the graphic's local matrix must be concatenated with its parent's local-to-global matrix. This concatenated matrix is cached by the graphic that provided it. The architecture provides this type of behavior. The graphic state must be "concatenated" to the state of its parent graphic, creating a new full set of states that apply to the graphic. When TGroup :: Draw is called, its parent TGrafPort object is passed. Since T Group 500 does not have its own state, it does not perform any concatenation, it simply passes the parent's TGrafPort object to the polygon's Draw call, then to the ellipse's Draw call. Polygon 502 has a TGrafBundle 504 that must be connected to its parent TGrafPort object. This is done by creating a "linked" TGrafPort subclass (TLinkedBundlePort) that can perform this concatenation. Next, a call to TLinkedBundlePort :: Draw (const TGPolygon &) is made. FIG. 6 shows the objects in the TPolygon Draw call. Elements 600, 602, 604, 610, 612 have corresponding elements already described with respect to FIG. FIG. 6 also has TGafState 608. The TLinkedBundlePort object 606 is created locally for the TPolygon's 602Draw call, so this type of concatenation is temporarily present. This is necessary for some types of graphic hierarchy. For example, if a graphic hierarchy allows a particular graphic to be shared by two or more other graphics, then the shared graphic may have multiple parents, so Must be realized. For example, in FIG. 7, curve 706 is shared by graphics B702 and C710. Each GraphicB 702, GraphicC 710, TCurve 706 has an associated TGrafBundle 704, 712, 708, respectively. From GraphicA 700, a branch can be taken to either GraphicB 702 or GraphicC 710. The concatenation must be temporary because the result of the concatenation will be different depending on the branch taken (B or C). This is how the temporary hierarchy works. Graphical objects in the persistent hierarchy require knowledge of the parent information that the graphic can be drawn using the parent's state even though the parent is not actually drawn. A view system is an example of such a graphic hierarchy. A few things can be said about the persistent hierarchy. 1. Graphics in this hierarchy cannot be shared by multiple parents. 2. Special semantics, such as LinkTo and Unlink calls, parameterless Draw calls must be added to the graphics class used in this hierarchy. 3. You can also use the TGarfPort subclass, which stores more private substate objects, such as the 2D View Matrix State and Clip State objects. Therefore, each graphic will want to maintain its own private device cache. 4. If multitask-safe is needed, it will be realized. Efficiency It is important to pay attention to efficiency as many graphic state objects move around the system. There are two important things. 1. Simple MGraphics should only include "deltas" or changes in the parent's state. For example, a TPolygon object should only contain TGrafBundle objects. 2. Some state variables are shared by multiple graphics. The first important point is that the abstract nature of this architecture draws attention, and it is recognized that different TgrafPort subclasses contain only the necessary parts. The second important thing is that attention is paid to using shared attributes. Sub-States The following classes are "sub-states" classes accessed through the TGrafPort class. They provide access to the actual graphic state variables. Most of them, like TG rafPort, are abstract classes that define only "getters". Subclasses provide implementations of how state variables are "gotten". Substate classes have different semantics that connect with their parents. The LinkTo function provides a temporary connection from a child object to its parent so that concatenation occurs. The Unlink function serves this purpose. These semantics are used for two reasons. 1. The concatenated value can be cached by the child. 2. The child-to-parent binding also needs to be more durable than the more typical transient case. For more information on LinkTo and Unlink, see the chapter "Using LinkTo and Unlink" below. Substates are shown below. A. TAttributeState The TAttributeState class contains information about the appearance of graphics as they are drawn. This class definition is shown below. B. TMatrixState The TMatrixState class defines a 2D coordinate system. TMatrixState contains a protocol that accesses a matrix that transforms from a local coordinate system to some global coordinate system (typically the world coordinate system). The TLinkableMatrixState class defines a protocol that supports linking or concatenation with another TMatrixState object. This linking action has two reasons in the subclass. 1) Not required by clients accessing the matrix (eg T Graf Device). 2) Different linking interfaces may be used by advanced clients. The class definition is shown below. C. TClipState The TClipState class defines a shape or boundary to clip. It contains the protocol to access the clip area and is used by the device during rendering. The TLinkableClipState class defines a protocol that supports linking or concatenation with another TClipState object. This concatenation operation has two reasons in the subclass. 1) Not required by clients accessing the clip area (eg TGrafDevice). 2) Different linking interfaces may be used by advanced clients. The class definition is shown below. D. TSceneState The TSceneState class contains information about a scene as a whole. This information is normally only specified once per scene. It contains the following members: The Lights Camera class definition is shown below. E. FIG. TMatrix3DState The TMatrix3DState class defines a 3D coordinate system. TMatrix3DState contains a protocol to access a matrix that transforms from a local coordinate system to some global 3D coordinate system (typically a 3D world coordinate system). The TLinkableMatrix3DState class defines a protocol that supports linking or concatenation with another TMatrix3DState object. This linking action has two reasons in the subclass. 1) Not required by clients to access the matrix (eg TGrafDevice). 2) Different linking interfaces may be used by advanced clients. The class definition is shown below. F. Using LinkTo and Unlink The LinkTo and Unlink functions are typically called only from within "linked" TGrafPort objects, so you'll rarely need to call them directly. Calling them directly results in exception-hostile code. If an exception is thrown between the LinkTo and Unlink calls, the Unlink call will never be made. Bad news. The good news is that you can use the supplied TgrafPort subclass if it needs to be called directly in your code, or you can subclass TGrafPort yourself if you need special behavior. That is. Like other linked port classes, you should call the LinkTo function in the constructor and the Unlink function in the destructor. System-Supplied Subclasses The graphics system provides several useful subclasses of the Graphic State class. Some of them are explained below. A. TGrafPort Subclass As shown in FIG. 8, the TRootGrafPort class 902 contains default values for each substate 904-912. All substates reach TGrafPort 900 via TRootGrafPort 902. Therefore, it represents a World Coordinate space with an infinite clip area. It has a pointer to the TGrafDvice object and owns the device cache that it gets from the device. Use of this class should render only off-screen by the client. Use within on-screen results in drawing across the entire screen. As shown in FIG. 9, the TLinkedBundlePort class 1002 serves as the concatenation of the “parent” TGrafPort object 1000 and TGrafBundle object 1004. It is used when a local bundle needs to be bound to an attribute state object in the parent TGrafPort object 1000. The rest of the parent state is inherited. The TLinkedViewMatrixPort class 1006 serves as a connection between the parent TGrafPort object 1000 and the specified view matrix 1008. It is used when a local view coordinate system is desired. It concatenates the specified matrix to the view matrix in the parent TGrafPort object 1000. The rest of the parent's state is inherited. Alternatively, if caching of a concatenated matrix is desired, the matrix state object is passed instead of the matrix. The TLinkedModelMatrixPort class 1010 serves as a connection between the parent TGrafPort object 1000 and the specified model matrix 1012. It is used when a local model coordinate system is desired. It concatenates the specified matrix to the model matrix in the parent TGrafPort object 1000. The rest of the parent's state is inherited. Alternatively, if caching of a concatenated matrix is desired, the matrix state object is passed instead of the matrix. The TLinkedClipAreaPort class 1014 serves as a connection between the parent TGrafPort object 1000 and the TGArea1016. It is used when the local clip region needs to intersect with the clip region in the parent TGrafPort object 1000. The rest of the parent's state is inherited. Alternatively, if caching of the attached clip areas is desired, the clip state object is passed instead of the clip areas. The TLinkedScenePort class 1018 serves as a connection between the parent TGrafPort object 1000 and the TSceneState object 1020. It is used when the local scene state needs to be concatenated with the scene state in the parent TGrafPort object. The rest of the parent's state is inherited. The TLinkedModelMatrix3DPort class 1022 serves as a concatenation of the parent TGrafPort object 1000 and the specified 3D model matrix 1024. It is used when a local 3D model coordinate system is desired. It concatenates the specified matrix into the 3D model matrix in the parent TGrafPort object. The rest of the parent's state is inherited. Alternatively, if caching of a concatenated matrix is desired, the matrix state object is passed instead of the matrix. B. TAttributeState Subclasses These subclasses virtually have any appearance attributes of the graphics processing system. C. TMatrixState Subclass As shown in FIG. 10, TSimpleMatrixState 1104 contains a local 2D matrix 1106. The local matrix concatenates via 1102 with the parent's local-to-global matrix to create its own local-to-global matrix 1100. This is what is returned by GetMatrix. D. TClipState Subclass FIG. 11 is a diagram showing the relationship of the TClipState subclass 1200. The TSimpleClipState class 1204 contains a single TGArea object 1206 as its local clip area. The local clip area intersects with its parent clip area to create the clip area returned by GetClipArea. GetClipAreaWithChildren returns the same clip area. A more sophisticated TinkableClipState subclass 1202, defined by the view system, incorporates its children's clip regions into the equation. It subtracts their clip area from itself to create a new clip area returned by GetC lipArea. See the View Systems literature for more information. E. FIG. TSceneState Subclass The TSceneState subclass holds information about the scene as a whole. For example, this subclass may have a light and a camera. F. TMatrix3DState Subclass FIG. 12 is a diagram showing relationships established for TMatrix3DState 1300. The TSimpleMatrix3DState class 1304 contains a local 3D matrix 1306. The local matrix is concatenated with the parent's local-to-global matrix to create its own local-to-global matrix. This is what is returned by GetMatrix. TLinkkableMatrix3DState 1302 provides a mechanism for linking TSimpleMatrix3DState 1304 and TMatrix3DState 1300. Usage by MGraphic In order to support the MGraphic hierarchy, the parent state must be passed to the MGraphic :: Draw call so that the child can concatenate its own state with the parent state. void Draw (TGrafPort &parentPort); MGraphic subclasses need more specialized behavior (ie views) and must define special semantics to support it. Examples of usage A. Graphic Hierarchy When a particular matrix state object is asked, "Give me a local-to-global model matrix," the answer sometimes depends on the local-to-global model matrix of the parent state. Consider the graphic hierarchy of FIG. This graphic consists of two groups of smaller graphics, group 1 shown at 1400 and group 2 shown at 1402. Group 2 contains polygons and is located within Group 1, which also contains ellipses. The TSimpleMatrixState objects that both groups contain define their model coordinate system. Group 1 represents the screen, meaning that its parent matrix is the same. If asked "Give me a local vs. global model matrix", Group 1 simply returns its own local matrix. When Group 2 is asked the same question, it pre-concatenates its own local model matrix with the Group 1 local versus global model matrix and returns the result. Maybe it will cache the result. B. Example Different subclasses of the above abstract class implement specialized behaviors. The specialized operations have: 1. Different connection behaviors of hierarchical state variables, eg clipping region calculation. 2. Different override behavior of non-hierarchical variables, eg antialiasing control. 3. Different storage requests. Most of the time it is only necessary to store a subset of the states. 1. Simple MGraphics (TPolygon) Simple MGraphics like TPolygon only need to specify the attributes (drawing operations, fill and frame paints, etc.) contained in the TGrafBundle class. The TPolygon Draw call is shown below. Note that you use the overriding bundle parameter of the TGrafPort :: Draw call. 2. More Complex MGraphics Some MGraohics require more state than TGrafBundle objects. Shown below is a Draw call for a graphic that stores a TTGrafBundle and a local model matrix. 3. Direct drawing on the screen Direct drawing on the screen is done in this way. 4. Direct Drawing on Screen with Clip Boundaries Direct drawing on the screen using nested clip boundaries and coordinate system is performed in this way. 5. Drawing Back-Buffered Graphics Back-buffering graphics own a device that acts as a "cache" for their children. For example, for frame buffer, the back buffer is TGImage. When concatenation with the parent occurs, the back buffer is validated for the passed device. If it is a valid back buffer for the given device, it will be drawn to the device. Otherwise it is deleted and replaced with a new back buffer. This behavior is wrapped in the TLinkedBackBufferGrafPort class. The following is one of several ways this feature can be implemented. Note that the TBackBufferingGraphic class can act as a "wrapper" for another MGraphic that knows nothing about backbuffering. C. Example Consider the MGraphic in Figure 14. It consists of a single TGroup 1500 containing a single TPolygon 1506. Both contain some local state. The TMyGroup 1500 includes a local state TGrafBundle 1502 and a TSimpleMatrixState 1504. The TPolygon 1506 contains a local state TGrafBundle 1508. FIG. 15 is a detailed logic flow chart according to the preferred embodiment. Processing begins at function block 1600. Here, a graph port is generated that connects the matrices using the logic in function blocks 1640 and 1650. In function blocks 1640 and 1650, matrix state objects are created and linked to parent port matrix state objects to facilitate concatenation. Next, in function block 1610, a loop is started to draw into the port just created. This is achieved as follows. Pass the polygon or other geometry to the graph port in function block 1660. In turn, the graph port passes the polygon or other geometry and its graphic state object in function block 1670 to the graphics device. Next, in function block 1680, the device obtains a matrix from the passed graphic state object. Next, a test is performed at decision block 1690 to determine if the concatenated matrix is old with respect to the parent and local matrices. If old, the parent and local matrices are concatenated in function 1692 and the result is returned to the graphics device in function block 1694. The loop started at function block 1610 includes the test at decision block 1620 to determine if the last graphic object has been processed. If so, the graph port created in function block 1600 is deleted in function block 1630, and the matrix state of the graph port is unlinked from its parent in function block 1632. Although the present invention has been described in terms of a preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the following claims.

[Procedure Amendment] Patent Act Article 184-8 [Submission date] November 20, 1995 [Amendment content] (Original specification page 1) Specification Graphic status processing Copyright notice , Including materials under copyright protection. The copyright owner has no objection if the copy is either in the patent document or the disclosure of the patent, such as would appear in the Patent and Trademark Office patent file or records, but in any other case, All copyrights are reserved. CROSS-REFERENCE This patent application is related to a patent application called OBJECT ORIENTED GRAPHIC SYSTEM filed on November 3, 1993, and is assigned to Taligent. The disclosure of which is incorporated herein by reference. FIELD OF THE INVENTION The present invention relates generally to improvements in computer systems, and more particularly to systems and methods for graphic state processing. BACKGROUND OF THE INVENTION In previous graphics architectures, a graphic typically stored its state (eg, color, transfer mode, clip area, etc.) privately. When asked to draw, the graphic procedurally copies these state variables into the GrafPort, which are accessed by the rendering code. Therefore, the state of this graphic is only available during this explicit drawing operation. This is a limitation that graphic systems, not object-oriented, cannot do. Another problem with prior art graphics architectures is forcing a graphics hierarchy within a graphic object because that object interacts with that object while it is drawing. is there. Haralick, RM. Et al., "The Image Understanding Environment", SPIE, vol.165 9, Imaging processing and Interchange, discloses a standard for graphic geometry in procedural programming systems. Various geometries are defined for a particular geometry as containing the appropriate type of data. The definition of a category of curved geometry is the specific information presented in that paper. "Computer Graphics: Principles and Practice" by Foley, JD, Addison, Wesley Publishers, 1992, 2nd edition, pp.292-4, 318-321 and 332 are retained mode graphics. A brief overview of the system (retain mode graphic system) is disclosed. This paper does not describe or suggest the use of object-oriented design. Furthermore, there is no explanation or suggestion that the object consists of methods and data for specialized graphic objects as described below with respect to the present invention. The article also requires that for each geometry that appears on the display, ordinary ret ain mode features that duplicate a copy of all the information associated with the geometry. This paper also describes a technique for inheriting the attributes of graphic entities on a display by means of a procedural data structure that implements the inheritance technique. SUMMARY OF THE INVENTION Therefore, a first object of the present invention is to provide a system and method for processing graphic states. It is a further object of the present invention to provide a system and method that provides access to a graphic state other than the graphic that uses the graphic state. These and other objects of the invention are to provide a method and system having a graphics state object used by a graphic to render that graphic. Graphic state objects may also include the ability to establish relationships with rendering devices and associated caches. In addition, the state object contains a number of sub-states. Claims 1. In the graphic state processing apparatus (10-38), (a) processor means, (b) storage means (16, 14) attached to the processor means (10), and (c) the processor means (10). A graphics device (36, 38) means under control of (d) the nature of one or more geometry (302) and the graphics state associated with said one or more geometry (1402) A graphic object (400) containing logic and data defining information (904, 906, 908, 910, and 912); and (e) an application means located in said graphic object (1 610). The geometrical figures (1600, 1660) that are present, and the application means (1600). And an application means for presenting the geometric figure (1660) on the graphic device (1670, 36, 38) from the graphic object (1610) using the graphic state (1680). And the device. 2. The apparatus of claim 1, wherein the graphic states (904, 906, 908, 910 and 912) include a plurality of sub-states. 3. 3. The apparatus according to claim 2, wherein the graphic state (904, 906, 908, 910 and 912) sub-states includes appearance rendering means. 4. Device according to claim 2, characterized in that sub-states of the graphic states (906, 910) include coordinate means. 5. 3. The apparatus of claim 2, including clipping means in a substate of the graphic state (908). 6. 3. The apparatus of claim 2, including scene means in a substate of the graphic state (912). 7. An apparatus according to claim 1, including communication means for communicating information belonging to a set of devices attached to said apparatus (34, 23). 8. The apparatus of claim 1, including cache means for storing graphic information (406). 9. The device according to claim 1, wherein: (a) a storage unit that receives a function for drawing from the application (14); (b) a storage unit that receives the graphic state information (14); and (c) the device (404, 34 and 23), including means for sending the drawing function and the graphic state to the set of devices attached to 34 and 23). 10. 10. The apparatus of claim 9, including means for caching information (406). 11. Apparatus according to claim 9, characterized in that the graphics device is a display (38). 12. The apparatus of claim 1 including means for performing a concatenation of graphic state objects (1002, 1006, 1010, 1014, 1018 and 1024). 13. 10. The apparatus according to claim 9, wherein the graphic device is a printer (20). 14． Device according to claim 9, characterized in that the graphic device is a plotter (21). 15. A method of graphic state processing in a processor having attached storage and display, comprising: (a) the nature of one or more geometry (302) and the graphics associated with said one or more geometry (1402). Defining a graphic object (400) containing logic and data defining state information (904, 906, 908, 910, and 912); and (b) geometry placed on said graphic object (1610). Processing a graphic (1 600, 1660), (c) utilizing the graphic state (1680) from the graphic object (1610) onto the graphic device (1670, 36, 38) S which presents (1660) Method which is characterized in that a-up. 16. The method of claim 15 including the step of storing a plurality of sub-states in the graphic state (904, 906, 908, 910 and 912). 17． The method of claim 16, comprising performing a rendering of an appearance based on substates of the graphic states (904, 906, 908, 910 and 912). 18. The method of claim 16 including the step of performing coordinate processing based on information in substates of the graphic state (906, 910). 19. The method of claim 16, including performing clipping on the graphic based on information in substates of the graphic state (908). 20. The method of claim 16, including performing a rendering of a scene based on information stored in substates of the graphics state (912). 21. 16. The method according to claim 15, comprising the step of communicating information belonging to a set of devices (34 and 23). 22. The method of claim 15, comprising storing graphic information in a cache (406). 23. The method of claim 15, wherein (a) receiving a function to draw from the application (14), (b) receiving information (14) on the graphic state, and (c) a set of devices (404, 34). And 23) sending the drawing function and the graphics state to 23). 24. 24. The method of claim 23 including the step of sending the graphics state to the cache means (406). [Fig. 2]

────────────────────────────────────────────────── ─── Continuation of front page    (81) Designated countries EP (AT, BE, CH, DE, DK, ES, FR, GB, GR, IE, IT, LU, M C, NL, PT, SE), OA (BF, BJ, CF, CG , CI, CM, GA, GN, ML, MR, NE, SN, TD, TG), AT, AU, BB, BG, BR, BY, CA, CH, CN, CZ, DE, DK, ES, FI, G B, HU, JP, KP, KR, KZ, LK, LU, LV , MG, MN, MW, NL, NO, NZ, PL, PT, RO, RU, SD, SE, SK, UA, UZ, VN (72) Inventor Ryoji Watanabe             United States 95014 California             Province Cupertino Palm Avenue             22284

Claims (1)

[Claims] 1. In the graphic state processing device,   (A) processor means,   (B) storage means attached to the processor means,   (C) a graphics device means under the control of said processor means;   (D) a graphic state in the storage means having a graphic state Object and   (E) Application means, which are stored in the storage means How many graphics are processed and the application means and the graphic state Application to utilize to present the geometry on the graphics device And means An apparatus comprising: 2. The apparatus of claim 1, wherein the graphic state includes a plurality of substates. Device. 3. 3. The apparatus according to claim 2, wherein the appearance of the sub-state of the graphic state is changed. An apparatus comprising a soldering means. 4. The apparatus according to claim 2, wherein the sub-state of the graphic state is coordinate means. An apparatus comprising: 5. The apparatus according to claim 2, wherein the sub-state of the graphic state is clipped. A device comprising a plugging means. 6. The apparatus according to claim 2, wherein a scene state is added to a sub state of the graphic state. An apparatus comprising a step. 7. The device according to claim 1, which belongs to a set of devices attached to the device. An apparatus comprising communication means for communicating information. 8. The cache device for storing graphic information according to claim 1, An apparatus comprising a step. 9. The device of claim 1, wherein   (A) storage means for receiving a drawing function from the application,   (B) storage means for receiving information on the graphic state,   (C) To the set of devices attached to the device, the drawing function and the graphics And a means to send An apparatus comprising: 10. The apparatus of claim 9 including means for caching information. Device to collect. 11. 10. The apparatus of claim 9, wherein the graphics device is a display. A device characterized by being a. 12. The apparatus of claim 1, wherein the connection of graphic state objects is implemented. An apparatus comprising means for performing. 13. The apparatus of claim 9, wherein the graphics device is a printer. An apparatus, comprising: 14． The apparatus of claim 9, wherein the graphics device is a plotter. An apparatus, comprising: 15. In a processor with attached storage and display In the method of rough state processing,   (A) A graphic state object having a graphic state in the storage The steps to build   (B) processing a graphic placed in said storage means;   (C) The graphic is displayed on the display based on the graphic state. And the step of displaying A method comprising: 16. The method of claim 15, wherein the graphic state includes a plurality of substates. A method comprising: storing a. 17． The method of claim 16 based on a sub-state of the graphic state. And performing a rendering of the appearance. 18. The method of claim 16, wherein the substate of the graphic state is A method comprising performing coordinate processing based on the information provided. 19. The method of claim 16, wherein the substate of the graphic state is Performing clipping on the graphic based on the information A method characterized by the following. 20. The method of claim 16, wherein sub-states of the graphic state are stored. The step of performing a rendering of the scene based on the information provided. Features method. 21. The method according to claim 15, wherein a step of communicating information belonging to a set of devices. A method comprising: 22. The method according to claim 15, wherein graphic information is stored in a cache. A method comprising the steps of: 23. The method of claim 15, wherein   (A) receiving a drawing function from the application,   (B) a step of receiving information on a graphic state,   (C) A step of sending the drawing function and the graphic state to a set of devices. And A method comprising: 24. 24. The method of claim 23, wherein the graphics to the cache means. A method comprising sending a state. 25. 24. The method of claim 23, wherein the set of devices attached to the method is special. A method comprising sending an encrypted condition. 26. The method of claim 15, wherein the linking of graphic state objects is A method comprising performing steps.