mangin@debussy.inria.fr (Frank Mangin) (11/09/90)
-- Found in the Xlib sources, file XImUtil.c: "* The logic contained in these routines makes several assumptions about * the image data structures, and at least for current implementations * these assumptions are believed to be true. They are: * * For all formats, bits_per_pixel is less than or equal to 32. * For XY formats, bitmap_unit is 8, 16, 24, or 32 bits. * For Z format, bits_per_pixel is 4, 8, 12, 16, 20, 24, 28 or 32 bits. " Why isn't it in the doc? The Xsun server recently posted on comp.sources.x, that runs on sun's 24 bits displays, supports a DirectColor visual with 11 bits for red and green... any solution??? I wouldn't like to rewrite the Xlib! Furthermore, I have a small bugs, but no time to make an official report: 1) On a sun 4/60, 8-bits color display, SunOS4, running MIT X11R4 server, under twmR4: I create a window with a DirectColor visual, and an appropriate colormap (XCreateColormap with AllocAll argument). I enter the window (the colormap gets installed), store colors in the colormap using XStoreColors, and the changes are NOT "immediately visible" (Xlib doc). Now if I leave and reenter the window, the changes are visible. I can't say if this is a twm or an XLib bug. And last some questions: - the Xsun server from comp.sources.x supports a PseudoColor visual. The colormap_size field in the visual info of this visual is 1. Is this in fact 2^32 put in an unsigned long, or is this a silly visual? - Can I use XAllocColor with a static colormap? If yes, this doesn't work for the Xsun server from comp.sources.x (the pixel value returned is always 0). If not, how can I know which pixel value will give a given rgb color? - What mean the mask fields of the XVisualInfo structure for a DirectColor visual, since you will allocate colors using XAllocColorPlanes, which returns new mask values? Frank Mangin Inria Phone #93 65 78 66 2004 route des Lucioles Email: mangin@mirsa.inria.fr 06560 Valbonne Cedex France
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (11/10/90)
In article <9001@mirsa.inria.fr>, mangin@debussy.inria.fr (Frank Mangin) writes: |> 1) On a sun 4/60, 8-bits color display, SunOS4, running MIT X11R4 server, under twmR4: |> I create a window with a DirectColor visual, and an appropriate colormap (XCreateColormap with AllocAll argument). I enter the window (the colormap gets installed), store colors in the colormap using XStoreColors, and the changes are NOT "immediately v|> isible" (Xlib doc). Now if I leave and reenter the window, the changes are visible. I can't say if this is a twm or an XLib bug. It is not possible in HARDWARE for the changes not to be immediately visible. Are you issuing an XFlush Call after XStoreColors? |> |> - Can I use XAllocColor with a static colormap? If yes, this doesn't work for the Xsun server from comp.sources.x (the pixel value returned is always 0). If not, how can I know which pixel value will give a given rgb color? XAllocColor should ALWAYS work for any colormap. Are you checking the return value? I am not too familiar with Static Color displays, but I would imagine that if the color you asked for was not there, XAllocColor would fail (I believe that StaticColor colormap is READ ONLY). -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776