nanogui: Pixmaps


Previous by date: 20 May 1999 16:53:42 -0000 Re: Bitblt proposal (was: Re: bogl routines), Greg Haerr
Next by date: 20 May 1999 16:53:42 -0000 Re: nanoX for ELKS, Alistair Riddoch
Previous in thread: 20 May 1999 16:53:42 -0000 Re: Pixmaps, Greg Haerr
Next in thread: 20 May 1999 16:53:42 -0000 Re: Pixmaps, Ben Pfaff

Subject: RE: Pixmaps
From: Greg Haerr ####@####.####
Date: 20 May 1999 16:53:42 -0000
Message-Id: <01BEA2AE.CB6F49B0.greg@censoft.com>

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: ####@####.####
> 

Previous by date: 20 May 1999 16:53:42 -0000 Re: Bitblt proposal (was: Re: bogl routines), Greg Haerr
Next by date: 20 May 1999 16:53:42 -0000 Re: nanoX for ELKS, Alistair Riddoch
Previous in thread: 20 May 1999 16:53:42 -0000 Re: Pixmaps, Greg Haerr
Next in thread: 20 May 1999 16:53:42 -0000 Re: Pixmaps, Ben Pfaff


Powered by ezmlm-browse 0.20.