GEOS SDK TechDocs
|
| 
2 Getting Started: View Basics
| 
2.2 Defining the Basic View
The GEOS graphics system is explained in full in the Graphics Environment chapter. Some of it is reviewed here, although you should read the graphics discussions to fully understand how to draw a graphic document.
The GEOS default document space is represented by signed, 16-bit coordinates relative to a central origin. Coordinates are in 72 points per inch, and documents that use this space can be up to 8192 points, or 113.8 inches, on a side. If your document must be larger than this, you may make use of the "large document" model, which uses 32-bit signed coordinates. Large documents can be over 940 miles on a side.
Every document is drawn to a GState which keeps track of such current state as pen position, color, rotation, and scale. You may apply transformations on the GState to get different rotation and placement within the document space.
To display a graphic document in a view, you must set up the view to have your Process object as its content. This means that your Process object must be able to draw the document, handle messages received from the view, and control the view's behavior as required. The Process object must also know how to support the UI mechanisms with which the view's content object might want to interact (such as the quick-transfer mechanism).
The view defaults to using the large coordinate space for all its operations, though this does not mean only large documents can be displayed in the view. Large documents are represented in a signed, 32-bit (long integer) document coordinate space. This means large documents may be up to 2,147,483,648 points high by 2,147,483,648 points wide (941.5 miles on a side). Because the graphics system is optimized for 16-bit operations, there are special considerations you must take into account when using a view to display large documents.
There are two basic ways to deal with 32-bit coordinates in a 16-bit graphics system. Both involve performing an extended translation on the GState in order to draw in a "local" 16-bit graphics space. The extended translation is performed with
GrApplyTranslationDWord()
, which takes two 32-bit coordinates and translates the GState's origin to those coordinates. Any 16-bit drawing operations are then automatically done relative to the new origin. All translations are cumulative.
One of the two ways to handle large documents is to apply the extended translation before each drawing operation and untranslate after each operation. This obviously incurs quite a bit of additional overhead.
The other way of handling large documents is to "tile" them, just as the Spooler does when printing large documents on small paper. In this case, you would apply the extended translation once, from then on drawing in 16-bit coordinates relative to the local origin. When you wanted to move to another tile, you would apply another extended translation to the new tile. The drawback to this is that your drawing code has to recognize when the 16-bit local boundaries are being crossed and a transformation is necessary.
GEOS SDK TechDocs
|
| 2 Getting Started: View Basics
| 2.2 Defining the Basic View