nanogui: Thread: Pixmaps

I just read the official X11 manual again (a very nice piece of
documentation- it's interesting to see how closely mini-X was modelled on
X) in an effort to understand something which has never made sense to me.
I still don't get it. Why do pixmaps have depth? There doesn't seem to be
any way of making use of anything other than the top layer, so what is the
point of letting them have an arbritrary number of layers? I can see the
point of server side bitmaps, sure, but what use are multi-layer pixmaps?
What would be more useful it seems to me is a way of storing something
along the lines of Allegro's BITMAP structure instead, which allows you to
describe an image of any size (within memory constraints) in any of the
several main bit-depths. What do you think?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

In message <Pine.LNX.4.04.9905200050410.5020-100000@hyperspace> Alex Holden writes:
: I just read the official X11 manual again (a very nice piece of
: documentation- it's interesting to see how closely mini-X was modelled on
: X) in an effort to understand something which has never made sense to me.
: I still don't get it. Why do pixmaps have depth?

XCopyArea can take a Pixmap of any depth, assuming that the Pixmap
depth matches the depth of the Drawable.  They can also be used as the
background pixmap for a window.

XCopyPlane is different in that it can only take a one bit drawable,
if I recall correctly.

: There doesn't seem to be
: any way of making use of anything other than the top layer, so what is the
: point of letting them have an arbritrary number of layers?

XCopyArea will take a pixmap of any depth.  Many window managers use
this for icons.  Some applications have a "zero repaint" time by
drawing into a Pixmap, then setting it as the background Pixmap for
the window.  This works well for things like clocks that you don't
want to have to bother refreshing every time something obscures it...

: I can see the
: point of server side bitmaps, sure, but what use are multi-layer pixmaps?

They aren't multi-layered, per se.  They are just hunks of data.  A 1
bit pixmap is the same thing as a 8 bit pixmap.  It isn't a good idea
to think of them as layers, because they really aren't.  True, a 1 bit
pixmap can be used as a clip mask, which gives the illusion of
layering, but it is just clipping.

So there is more there than meets the eye...  There are some limits,
and they are annoying and irritating, but they are generally useful.

Warner

On Wed, 19 May 1999, Warner Losh wrote:
> In message <Pine.LNX.4.04.9905200050410.5020-100000@hyperspace> Alex Holden writes:
> : I just read the official X11 manual again (a very nice piece of
> : documentation- it's interesting to see how closely mini-X was modelled on
> : X) in an effort to understand something which has never made sense to me.
> : I still don't get it. Why do pixmaps have depth?
> XCopyArea can take a Pixmap of any depth, assuming that the Pixmap
> depth matches the depth of the Drawable.  They can also be used as the
> background pixmap for a window.

That still doesn't explain it for me. What is the depth of the pixmap
actually used for? I'm sure it must be used for something, but I haven't
been able to figure out what... and how is it more useful than a generic
colour bitmap structure?

> They aren't multi-layered, per se.  They are just hunks of data.  A 1
> bit pixmap is the same thing as a 8 bit pixmap.  It isn't a good idea

Then why have 8 bit pixmaps?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

> : I can see the
> : point of server side bitmaps, sure, but what use are multi-layer pixmaps?
> 
> They aren't multi-layered, per se.  They are just hunks of data.  A 1
> bit pixmap is the same thing as a 8 bit pixmap.  It isn't a good idea
> to think of them as layers, because they really aren't.  True, a 1 bit
> pixmap can be used as a clip mask, which gives the illusion of
> layering, but it is just clipping.
> 

	Yes.  This is the idea.  There is one more bit (no pun) of detail
though between a monochrome and 8 bit pixmap, though.  The draw routines
will use the fg color for the 1 bits and bg color for the 0 bits in the pixmap, when
drawing.  The bigger bit-depth pixmaps use the system palette for each pixel,
where the pixel is the palette index.  Now, in some cases, it is desirable to carry
around an alternate palette with the bits.  This is the case with the .gif file format,
for instance.  In this case, the system repalettizes a portion of the system
palette to display the image.  I was thinking of writing all this code.

	Finally, with 15, 16, 24 and 32 bit pixmaps, the system builds a 32 bit
RGB value from each pixel, and then, either displays the color directly, if
running on >= 16 bit hardware, or, calls a FindNearestColor() function to convert
the color to the system palette.

	I have made the initial mods in the 0.5pre1 release to support all of
this.  That's the difference between a COLORVAL and PIXELVAL.

Greg

On Wednesday, May 19, 1999 5:58 PM, Alex Holden ####@####.#### wrote:
> I just read the official X11 manual again (a very nice piece of
> documentation- it's interesting to see how closely mini-X was modelled on
> X) 

	I have been reading the X manual for some time to ensure that
the off-by-one bugs, etc in nanoX were fixed according to "spec."


in an effort to understand something which has never made sense to me.
> I still don't get it. Why do pixmaps have depth? There doesn't seem to be
> any way of making use of anything other than the top layer, so what is the
> point of letting them have an arbritrary number of layers? I can see the
> point of server side bitmaps, sure, but what use are multi-layer pixmaps?

	I just gave a long answer to this in another email.

> What would be more useful it seems to me is a way of storing something
> along the lines of Allegro's BITMAP structure instead, which allows you to
> describe an image of any size (within memory constraints) in any of the
> several main bit-depths. What do you think?

	I like this idea alot.  This is the idea that Windows uses in there bitmap
structure on disk.  The idea is that the system allows blitting images
of any planes and bits per pixel, and then there are routines to deal with
conversion built in.  In addition, the windows bitmap structure v3.0 allows
a carry-along palette, which allows a complete self-contained specification
of the image (even if it is in a hardware-dependent format).

I suggest the following structure:

	typedef struct {
		COORD	 width;
		COORD height;
		int planes;
		int bitsperpixel;
		IMAGEBITS bits[];
		// image data here, optionally followed by color data
	} BITMAP;

	In addition, a tag along for palette data:
		int ncolors;
		COLORVAL palette[];



	Since nano-X doesn't have to be completely X-dependent, I don't see
anything wrong with adding some stuff that's quite a bit more fancy than what
X supports today.  We do have to be worried about breaking too many X api
calls, though.  But, so far, noone has tried to port any X program to nano-X anyway.

Greg




> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

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.

		   COORD height;
		   int planes;
		   int bitsperpixel;

Are `planes' + `bitsperpixel' enough?  You might need a `visual'
member also for odd image formats.

		   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?

	   } BITMAP;

	   In addition, a tag along for palette data:
		   int ncolors;
		   COLORVAL palette[];
-- 
"To the engineer, the world is a toy box full of sub-optimized and
 feature-poor toys." --Scott Adams

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

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.

On Thu, 20 May 1999, Greg Haerr wrote:
> I suggest the following structure:
> 
> 	typedef struct {
> 		COORD	 width;
> 		COORD height;
> 		int planes;
> 		int bitsperpixel;
> 		IMAGEBITS bits[];
> 		// image data here, optionally followed by color data
> 	} BITMAP;
> 
> 	In addition, a tag along for palette data:
> 		int ncolors;
> 		COLORVAL palette[];

Out of interest, here is the allegro structure. As you can see, it's quite
a bit more advanced, including information about whether to clip it, where
to clip it (relevant to its origin), allows it to be used for the hardware
itself, provides for sub-bitmaps, etc. At least some of these features are
probably useful.

typedef struct BITMAP            /* a bitmap structure */
{
   int w, h;                     /* width and height in pixels */
   int clip;                     /* flag if clipping is turned on */
   int cl, cr, ct, cb;           /* clip left, right, top and bottom
values */
   GFX_VTABLE *vtable;           /* drawing functions */
   void (*write_bank)(void);     /* write bank selector, see bank.s */
   void (*read_bank)(void);      /* read bank selector, see bank.s */
   void *dat;                    /* the memory we allocated for the bitmap
*/
   int bitmap_id;                /* for identifying sub-bitmaps */
   void *extra;                  /* points to a structure with more info
*/
   int x_ofs;                    /* horizontal offset (for sub-bitmaps) */
   int y_ofs;                    /* vertical offset (for sub-bitmaps) */
   int seg;                      /* bitmap segment */
   unsigned char *line[0];       /* pointers to the start of each line */
} BITMAP;

> 	Since nano-X doesn't have to be completely X-dependent, I don't see
> anything wrong with adding some stuff that's quite a bit more fancy than what
> X supports today.  We do have to be worried about breaking too many X api
> calls, though.  But, so far, noone has tried to port any X program to nano-X anyway.

I agree.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

> In other words, a subbitmap just represents a new view of existing
> bitmap data.
> 

	I like it.  It basically just changes the x,y origin, which in a wierd
way can be calcluated by changing the in-core mem addr.

> 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.
> 

	Sure it will.  The imagebits are then just piled in right next to each other,
as they say "imagebits are imagebits"...  ;-)

Greg