nanogui: Drawing modes
Subject:
RE: Drawing modes
From:
Greg Haerr ####@####.####
Date:
19 May 1999 17:56:13 -0000
Message-Id: <01BEA1EE.46E454D0.greg@censoft.com>
> The allegro bank code is some of the most *ingenious* code in
> allegro, and is the basis for the trickery to make screen graphics memory
> and offscreen graphics memory work the same with common drawing code.
>
> It has nothing to do with allocating a separate buffer, and blitting. This is far
> too expensive. Instead, the idea is, that all graphics primitives work on a "BITMAP *"
> structure. This structure has both a start memory address, and a set of
> banking code proc ptrs. All of the drawing primitives (of which bitblt is also
> one) then draw onto the memory address in the BITMAP *. This writes bits
> in either screen memory or offscreen memory. The trick is, that the bank
> switch code for graphics memory actually switches graphics memory banks,
> required by the hardware, while offscreen memory is instead "offseted" by
> the total bank size, and the bits drawn there. Cool, huh?
>
The other cool thing that allegro does that I've been thinking about
for a major driver design enhancement for nano-X, is that, using the above
routines, the offscreen bitmaps are drawn using the same bit-plane ordering
as the device memory. (Of course, since it's using the same code). Then,
when an offscreen bitmap wants to be displayed, it can be quickly bitblt'd, with
out plane adjustment for speed.
Currently, nano-x (mini-x api) doesn't support any means of programmatically
drawing to anything other than the screen. This can be a problem if, for instance,
an area needs to be background erased and then much of it written over again
with new contents. This will cause annoying flashes. Instead, there needs to be
a capability of executing both draws to offscreen bitmaps, and then a single bitblt
to the screen.
One more thing that could be cool about a design like this. "Pseudo-graphics"
drivers can be created, which essentially know about other common screen formats
(read color bitmap formats) and then these binary formats can be easily imported
and exported from the nano-X system.
Comments?
Greg
