Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
Moderator: | STAR::VATNE |
Created: | Mon Oct 30 1989 |
Last Modified: | Mon Dec 31 1990 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 3726 |
Total number of notes: | 19516 |
When creating an image of depth 4, using the XCreateImage routine, I have noticed that when looking in the bits_per_pixel field of the image structure, that it has filled it in with 8 (not 4) - the depth field is set to 4. I had meant to stuff the image data with the proper pixel value before creating the image, but I assumed that that it would stuff two pixels into each byte, and the space I allocated for the image data was assuming 4 bits per pixel (with appropriate padding at the end of scanlines) My question is: Is there a way to store a 4 plane image at 4 bits per pixel, or will an ximage 4 planes always take a whole byte for each pixel (and waste half the space). -Jonathan
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
1868.1 | See RDVAX::X | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Fri Dec 08 1989 08:58 | 14 |
See the similar discussion in the RDVAX::X conference, note 729, for more than you ever wanted to know about images. Essentially, the image structure is trying to set up the image according to the way the server wants it. Our servers tell clients that for depth 4, they nonetheless want 8 bits-per-pixel (i.e. 4 significant bits, 4-bit-pad per pixel). They can deal with the data much more efficiently that way. Xlib is (generally) designed so that you should be able to store images in the Image data structure in any format, and have Xlib convert to what the server wants in real time. Unfortunately, conversion of bits-per-pixel is not implemented (I just found out). In any case, the conversion would probably take longer than whatever you might save in paging from less memory use. Burns |