Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: OS Graphic Card Support: Part II!
Message-ID: <19329@cbmvax.commodore.com>
Date: 27 Feb 91 04:19:11 GMT
References: <18989@cbmvax.commodore.com> <1991Feb18.210422.5446@sat.com> <1991Feb20.090728.2384@kberg.se> <1991Feb23.203900.27912@sat.com> <1991Feb25.090714.3701@kberg.se>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 52

In article <1991Feb25.090714.3701@kberg.se> svante@kberg.se (Svante Gellerstam) writes:

>Ok, I just wanted you to spell it out for me. The thing I have been
>trying to get acceptance for (breaking down open doors?) is some
>proposal towards a DIG standard for Gfx cards.

Nothing wrong with trying.  Thing is, lots of people will tell you to wait
until C= comes out with one.  Seems to me that's not absolutely necessary;
if a standard is truly device independent, then you can build a soft device
driver for one standard to support all devices in another standard.  I would
personally rather see programs even support two standards, rather than 100
different low level hardware register conventions, on a per-program basis,
like they do on the PC.

>Now, when I have you attention, I would like to hear (see :-) if you
>have any suggestions to put forward on how a device driver for ANY gfx
>card should be put together.

There are two basic approaches.  The simplest is the way Microsoft Windows,
or in a sense the Bridge Card, does it.  Basically, it goes something like 
this.  The graphics.library agent is responsible for building the bitmap in 
its internal format, which doesn't necessarily correspond to any physical 
bitmap format.  All this library actually needs to know about the target 
graphics card is the resolution desired.  When it completes an operation, the 
graphics.library sends an update message to the display's device driver.  This
driver then proceeds to translate the internal bitmap form to something it 
can live with, and the image appears.  On the Amiga, an extended graphics 
library could still use the blitter to do all rendering, etc. so this has the 
advantage of being a rather small leap from where we are now; the library 
basically needs the ability to communicate with video display device drivers.
Another advantage is that device drivers are relatively simple.  The main 
disadvantage of this approach is that it's slow, and very difficult to 
improve with more advanced hardware.

The other approach is to treat the graphic library like an object description
language, more along the lines of the Mac's QuickDraw, HP's laser printer
command set, or Postscript (though Postscript is more far more sophisticated).
In this case, most of the drawing commands get sent to the device driver for 
the alternate display.  That device driver interprets each command for its
particular display's characteristics.  While some bitmap translation will
occur, the display driver will also be handling higher level commands.  This
has the effect of making the device driver much more complex, but allows it
to easily use an alternate processor to manage the bitmap rendering, as most
Postscript devices, and a few high end Mac display cards, so today.

>Svante Gellerstam		svante@kberg.se, d87sg@efd.lth.se


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"What works for me might work for you"	-Jimmy Buffett