The IGrafPort class is a convenient container of the graphic state that is associated with the undefined native rendering device, such as the GDI interface for Windows. Its most important function is that it supplies a set of nonvirtual draw calls that make it convenient for drawing geometries.
For convenience, the IGrafPort class provides 2D draw calls.
The large number of disjoint calls (as opposed to a polymorphic single call) enforces the rule that only a small, well-defined set of basic 2D geometries is supported by graphics devices.
IGrafPort also provides 2D draw calls that take an additional bundle and model matrix for convenience in certain specialized conditions. The draw calls use the graphics state set by subclasses of IGrafPort. ILinkedGrafPort is a very efficient way to set up hierarchical graphics states. You can make these states shared among the appropriate geometry objects to be extended. The graphic state includes attribute state (bundle), clipping area, and transformation matrices.
There are two kinds of transform matrices in rendering:
Member functions allow you to access the graphic state.
The 2D Graphics framework provides two distinct ways of rendering geometries on a device.
Note: Immediate and retained mode: In pure immediate mode rendering, the application objects are rendered without keeping any record of the information (geometry, attributes, hierarchies) used to render them, while in retained mode, the record of all objects, their hierarchies, and other related information is stored for rendering.
A subclass of IGrafPort inherits the set of convenient draw functions in the base class.
The IBaseRootGrafPort class contains an IRootGrafState object, which contains default values for every possible substate that is needed for rendering a geometry. It has a default graphic state setting.
IBaseRootGrafPort uses world_coordinate units to draw all the graphics. One unit is equivalent to one point (1/72 of an inch). Graphics that draw to IBaseRootGrafPort are resolution independent.
An ILinkedGrafPort can associate itself with one of the three types of graphic state information. These three types of graphic state are attributes, transformation matrix, and clipping information. The attributes are represented by an IAttributeState object. IAttributeState is an abstract base class of IGrafBundle, IFillBundle, and so on. The transformation matrix is represented by an IGrafMatrix object. The clipping information is represented by an IGArea object.
With this class, one can construct a hierarchy of "linked" ports each representing a different state. All state information are kept hierarchically so it is easy for one to change some states without reconstructing the hierarchy.
The IStatefulGrafPort class is similar to IBaseRootGrafPort because it contains an IRootGrafState object, which has a full set of graphic states that is needed for rendering a geometry. It also has a pointer to an IGrafDevice object. The difference from the IBaseRootGrafPort is that you can set the value of the graphic states individually, and therefore it provides greater flexibility. This gives you a simpler API, but you have the responsibility of determining which of the states needs to be set and structuring the graphic state information. This is not as efficient as ILinkedGrafPort because the way hierarchical state linking can be shared among draw callers.
Note: This class is provided for experimental use and is subject to change. Use it for special case implementation only.
For any primitives that the native platform does not support, a subclass of IGrafDevice called IFrameBuffer can perform appropriate rendering in software to form the raster image. Along the way of rendering, the order of complexity of a high-level geometry with the specific attributes, transform, and clipping states can be reduced to a simpler geometry successively, until either a native operation can be carried out for such a geometry, or the resulting image can be constructed at the end. For example, a circle defined by a center and radius is to be rendered with a gray pattern fill. If the native rendering engine does not support gray fill pattern for conics but does for polygons, the circle is discretized to a polygon and the native polygon with gray fill pattern is performed.
It may be that there will be a case that an image is created by loading from an images file and is drawn to both IBaseRootGrafPort and IRootGrafPort. The size of the image displayed in IBaseRootGrafPort will be bigger than the size of the image in IRootGrafPort. But if the image is used as a fill pattern to fill graphics in both IBaseRootGrafPort and IRootGrafPort, the images in both GrafPorts will be the same size.
![]()
Special GrafPorts in Open Class
![]()
Drawing a Simple IMDrawable IPolygon