nanogui: Pixmaps
Subject:
RE: Pixmaps
From:
Greg Haerr ####@####.####
Date:
20 May 1999 18:46:20 -0000
Message-Id: <01BEA2BE.81565FC0.greg@censoft.com>
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. Also, isn't
the line_len only required for screens? The width member also
is padded to the sizeof(IMAGEBITS), the basic image chunk size. In
nanoX currently, this is 2, whereas in some 32-bit os's it's 4. There
is speed improvement potential here at the expense of memory. I know
Vidal is interested in small memory footprints, though, and already wants
a smaller bogl_font pad, which is currently 4.
I can see that a line_len member in-core would be a big help
for the writing general drivers, see my comments below.
>
> 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?
>
> 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?
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. The incore
version definitely wants to use a pointer for the address, much like the allegro
architecture we've been discussing.
Greg
