August 92 - GRAPHICAL TRUFFLES
GRAPHICAL TRUFFLES
WRITING DIRECTLY TO THE SCREEN
BRIGHAM STEVENS AND BILL GUSCHWAN
Many developers want to go beyond the speed of QuickDraw. Writing directly to the
screen can allow you to create faster animation and graphics than possible with
QuickDraw. However, Apple has always maintained that writing to video memory is
unsupported, since it may cause your application to break on a future system. If you
write directly to the screen, your application will forfeit the use of many Toolbox
managers and will put future compatibility at risk. Since most applications require
the Window Manager and other basic Macintosh managers, writing to the screen is only
for a few specialized applications, such as video games and some animation packages
that compete on the quality and speed of graphics.
We're providing guidelines for writing to the screen in this column because we know
that some developers are already doing it. We also understand that, in today's market,
you need every advantage you can get in order to be competitive.
BEFORE YOU READ ON
The most important thing to remember isdon't write directly to the screen if you don't
have to . In general, only a few applications need to do this. If you're porting an
existing graphics or animation library from another system, or writing an application
that competes mainly on the speed of the graphics, writing directly to the screen may
be necessary. For any other applications, turn back now and forget about writing to the
screen.
Even if your application is animation intensive or a port from another system, we
recommend that you always attempt to use QuickDraw first. QuickDraw may be fast
enough for your purposes, and it would not be wise to sacrifice its compatibility and
flexibility for no reason. You should always have a QuickDraw version of your code
anyway, and it should be the default, in case your program isn't compatible with the
system or video card being used. Writing directly to the screen should be a user-
selectable option.
As an alternative to writing to the screen, your application may be able to increase
graphics performance by using custom drawing routines in a GWorld and CopyBits to
transfer your image to the screen. This allows you to have faster graphics while
avoiding the compatibility nightmare that you may face by writing directly to the
screen. To learn more about custom drawing routines, see "Drawing in GWorlds for
Speed and Versatility" indevelop Issue 10.
We hope we've scared almost everyone away. For those of you still reading, we want to
point out that violating one compatibility guideline doesn't mean your program should
break others: you still need to follow certain rules in order to peacefully coexist with
other applications. For example, don't assume the screen is a fixed size or depth. Use
data structures like GDevice and screenBits to access this information (Inside
Macintosh Volume VI, page 3-7). So remember, most applications have no need to
write directly to the screen, and if you choose to do it, it may give you more
compatibility headaches than you're ready for. If your program breaks in the future
because you decided to write to the screen, it will beyour responsibility to fix it. We
feel that the methods outlined in this column will give you the best chance of future
compatibility; however, there are no guarantees.
WHERE'D THAT MANAGER GO?
In addition to risking compatibility problems, writing directly to the screen means
you have to do a lot of extra work. Specifically, you have to handle (or live without)
many of the tasks that Toolbox managers would normally handle for you.
You lose the full benefit of QuickDraw's graphics routines, most importantly the
clipping ability. Because the Window Manager uses QuickDraw for its clipping, you
lose the ability to have multiple overlapping windows as part of your application's
interface. If your application requires multiple overlapping windows, you don't want
to be writing directly to the screen.
You lose the ability to stretch your windows across multiple monitors. QuickDraw
automagically has the ability to split the contents of a window across multiple
monitors. If you write directly to the screen, you'll be limited to one monitor, or
you'll have to write a lot of code that has already been implemented in QuickDraw.
You lose the Help Manager. The Help Manager displays its balloons in a window over
your application's window. If you're writing directly to the screen, you'll blast the
Help Manager's windows.
You lose QuickDraw's ability to map pictures and pixMaps from one color environment
to another. Replacing such code with your own is nontrivial. Just try writing an
image-copying routine that deals with simultaneous multiple pixel depths and you'll
gain a new respect for CopyBits!
You restrict your ability to print. The Printing Manager only understands QuickDraw.
To print you'll have to use your drawing code to render your images and then use
CopyBits to transfer them to the printing grafPort. This means sacrificing quality on
the printed page, since pixMaps generally don't look as nice on the printer as objects
composed of QuickDraw calls. Of course, if you have a QuickDraw version of your code
you can easily work around this.
Your program may have a different look and feel than a standard Macintosh application.
In the case of video games and other animation packages, this may be OK . But if you're
writing the next- generation word processor or spreadsheet application, you should be
using QuickDraw, the Window Manager, and the Palette Manager. You lose all or most
of these user interface managers if you write directly to the screen. Do your writing to
the screen within a window; this will lessen the user interface impact. If you want to
take over the entire screen, open a window that covers the entire screen.
Your program will also need to know when it's running in the background (seeInside
Macintosh Volume VI, page 5-19). When you're in the background, other applications'
windows may be covering your window. In this case, youmust use QuickDraw to
refresh your window when you get an update event. If you write directly to the screen,
you may clobber the foreground application's window.