Graphics Environment: 4 How To Use Graphics

When looking at the source code of sample applications, it's usually not too hard to pick out the commands that do the actual drawing. Commands with names like GrDraw...() generally are self-explanatory. It's not so easy to pick out the commands that set up an area in which the drawing will take place. Part of the problem is that there are many ways to display graphics; each is well suited for different tasks. This section of the chapter provides some practical knowledge about the various ways to display graphics and which situations are appropriate for each.

When possible, the best way to learn how to perform a graphics action is to look at code which performs a similar action. The sample program presented in the Hello World chapter shows a simple graphics environment sufficient for many geodes. If you only need to change what is being displayed (as opposed to how it is displayed), you can work straight from the example, drawing different shapes using commands found in the Drawing Shapes chapter. Most basic graphics techniques are used in one sample program or another. By combining and adapting code from the sample programs, you can take care of most simple graphics needs.

If you can't find a sample geode to work from, there are several points to consider when deciding what sort of graphics environment to set up.

Sometimes the only graphics commands in a geode will be those used to define that geode's program icon. This is a common enough case that instructions for setting up your geode's icon are in the program topics section, .
Will existing generic UI gadgetry be sufficient for everything you want to display? If you're writing a utility, it might be. If you're writing an arcade game, it probably won't be.
If your geode will be displaying graphics, will the user ever interact directly with the graphics? A graphing program might draw a graph based on data the user types in. Such a program could draw the graph but might not actually allow the user to interact with the graph. On the other hand, an art program will probably expect the user to interact with the graphics directly.

Once you've figured out just what your geode's graphical needs are, you're ready to find out which pieces of graphics machinery are right for you.

For custom graphics that will appear in a view, the content object of the GenView must be prepared to issue graphics commands. A common tactic is to create a subclass of VisContentClass and let an object of this subclass act as the content for a view. The subclass would very likely have a specialized MSG_VIS_DRAW . The Process object is another popular choice for the view's output descriptor. In this case, the process must be prepared to intercept any messages the view is likely to send, with MSG_META_EXPOSED and MSG_VIS_DRAW of the most interest. Whichever object, process or content, is the content of a view can respond to MSG_META_EXPOSED or MSG_VIS_DRAW by calling kernel graphics routines. For more information on how to use these objects, see the Views chapter.

As you learn more advanced graphics concepts you may discover shortcuts. As you get deeper into graphics, you should keep a cardinal rule in mind. Any time the graphics space is obscured and then exposed, the geode must be able to draw correctly, no matter what changes have been made. If your geode only draws on a MSG_VIS_DRAW , it will automatically follow this rule. However, applications using shortcuts must take MSG_VIS_DRAW into account; it may be sent at any time, and what it draws may wipe out what was there before. An arcade game that moves a spaceship by blitting a bitmap may be fast; however, be sure that the spaceship will be drawn to the right place if the game's window is obscured and then exposed. Don't worry if this sounds confusing now, but keep these words in mind as you read on.

GEOS SDK TechDocs|

3 Graphics Architecture | Next:

5 Coordinate Space