nanogui: Pixmaps
Subject:
Re: Pixmaps
From:
Ben Pfaff ####@####.####
Date:
20 May 1999 19:03:50 -0000
Message-Id: <87k8u3r20w.fsf@pfaffben.user.msu.edu>
Greg Haerr ####@####.#### writes:
On Thursday, May 20, 1999 11:21 AM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
>
> I suggest the following structure:
>
> typedef struct {
> COORD width;
>
> Add a `virtwidth' or `line_len' member. Then you get subbitmap and
> subscreen (rectangular window) support "for free" with manipulation of
> the bits pointer.
I don't quite understand what a subbitmap is.
They're a frill, but they can be handy sometimes. Suppose that you've
got a bitmap, foo, that you're scribbling on. Suppose again that
you've got a function, frob, you wrote earlier that draws something
into a bitmap. It knows where it wants to draw it in the bitmap;
maybe it even uses the entire bitmap. But you want to put it as one
part of a bitmap that you're drawing on. Okay, so one thing you could
do is something like this:
create_bitmap (bar, ...) /* allocate bitmap and content */
frob (bar) /* frob bitmap bar. */
bitblt (foo, bar, ...) /* copy bar into (part of) foo */
A subbitmap is a small part of a larger bitmap. If you wrote the
above code using a subbitmap, you could write it more simply and it
would be faster too:
create_subbitmap (bar, foo, ...) /* allocate bitmap structure */
frob (bar) /* modify part of foo */
In other words, a subbitmap just represents a new view of existing
bitmap data.
Oh, wait a second--that doesn't work with bpp < 8. Fsck me I guess.
[...]
> COORD height;
> int planes;
> int bitsperpixel;
>
> Are `planes' + `bitsperpixel' enough? You might need a `visual'
> member also for odd image formats.
With planes and bpp you at least know enough to decode
the bits[] data. Of course, there may not be a decoder linked in for the
specific format found. We don't need to write a general purpose decoder
now anyway, since most of the bitmaps are created from real hardware
anyway.
What would the visual member do?
I was thinking about the specific case of oddly interleaved planes. I
think that some hardware does very strange things with plane-based
data.
>
> IMAGEBITS bits[];
> // image data here, optionally followed by color data
>
> Make it a pointer, not an array. Otherwise, how can you make a bitmap
> that's part of the screen?
Again, that won't work for bpp < 8. Fsck fsck fsck.
This struct of course still needs work. I was thinking of it's
use for general disk-based bitmaps, rather than the in-core
version.
Oh. That makes sense then.
The incore
version definitely wants to use a pointer for the address, much like the allegro
architecture we've been discussing.
Some of the stuff I'm spouting off today doesn't make much sense on
re-reading, maybe I should just shut up.
