Graphics container

Details Graphics container Graphics container

1999-07-30

2003-02-11

Luu, Matthew (Department: 2672)

Computer graphics processing and selective visual display system

Computer graphics processing

Graphic manipulation

C345S620000, C345S624000, C707S793000, C707S793000, C707S793000, C707S793000

Reexamination Certificate

active

06518976

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to image storage and processing in computers, and, more particularly, to a system wherein applications can define recursive, nested drawings of graphics rendered by other applications within containers.
BACKGROUND OF THE INVENTION
For years, applications and graphics libraries have struggled with how to support nested (i.e., embedded or contained) drawings, where one graphics file or drawing contains another graphics file or drawing which may contain yet another and so on (i.e., nested drawings). One example of this is a Windows® Metafile that contains a second Metafile. Another example is a document that contains an ActiveX control.
There are several problems associated with nested graphics and drawings. A first problem is preventing the embedded child from invalidating the state of a graphics context of the parent while the embedded child draws within another graphics context defined by the parent. This problem was solved in-part by the Windows® Graphics Device Interface (GDI) by the SaveDC and RestoreDC APIs, which can be used to save the state of the graphics context to a stack before the nested drawing starts and to restore the saved state from the stack after the nested drawing is completed. However, this solution is limited because the stack must be carefully managed, otherwise the parent's graphics context may be violated.
Another problem is that the prior art does not provide a mechanism by which a parent drawing can specify and enforce the position, size, and orientation of the nested child drawing. For example, an application can use GDI to set a graphics transformation and clipping state before a nested drawing starts, but the child drawing can reset the transformation and clipping at-will, thus invalidating the graphics state the parent set for the child drawing to use. An additional limitation is that drawings cannot be rendered the same way in both embedded and non-embedded contexts without the child application actually knowing that its graphics are being embedded. For example, if an application using GDI sets a transformation in the graphics context before starting a nested drawing, when the nested drawing queries the current transformation from the graphics context, the transformation that was set by the parent will be returned, whereas, if the same drawing was not embedded, an identity transformation would be returned. This requires different handling of the drawing operations by the child when it is embedded versus when it is not.
In view of the above, there is a need for an improved graphics engine in a computing device that overcomes the limitations of the prior art. In particular, there is a need for a graphics engine capable of embedding graphics and drawings without an application having knowledge that it is being embedded within a parent application's graphics context. Further, there is a need for a graphics engine that prevents alteration of the parent's graphics context by an embedded child application. Still further, there is a need for a graphics engine that provides a solution to the problems associated with nested graphics by making recursive, nested drawing easy for an application to accomplish. The present invention provides a solution to these problems.
SUMMARY OF THE INVENTION
The present invention addresses problems associated with nested drawings by providing BeginContainer and EndContainer APIs that are invoked by a parent application to begin and end a container within which an embedded child will render its graphics. The BeginContainer API pushes the current state information (e.g., graphics context) to a container stack and sets a new container transformation and a container clip region in the graphics context where the contained graphics will be displayed. The current world-to-device transformation is concatenated with the container transformation and the current visible clip region is intersected with the container clip region for transforming the child graphics to the container. Further, an identifier is used to prevent the child from altering the container transformation set by the parent, and from popping the container state stack.
After the container is set by the parent application, the world and page transformations of the child application are set to default values and the clipping region is set to infinity. The child application draws graphics to the container without any knowledge that it is being contained. The child is free to shrink the clipping that was set by the parent, but cannot expand it. When the EndContainer API is called by the parent application, the container stack is popped and the graphics context is restored to the state prior to calling the BeginContainer.
Other features of the invention are described below.


REFERENCES:
patent: 3763365 (1973-10-01), Seitz
patent: 5420980 (1995-05-01), Pinedo et al.
patent: 0 809 210 (1997-11-01), None
patent: 0 818 742 (1998-01-01), None
patent: 0 858 030 (1998-08-01), None

Affiliated with

Also associated with

Rating

Graphics container does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Graphics container, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Graphics container will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3159702