> this probably isn't a debian specific error, but i think it might have > something to do with how i have the system set up. i'm logging in > remotely to an SGI IRIX machine and attempting to run an X > application. it fails with something like the following error: > > Error initializing colors for colormap
I could probably help more if you were running Accelerated-X, as I know that X Server rather better than XFree86... but I have some wild guesses. Does the application require overlays? Some workstation applications expect to use both 24 bit and 8 bit windows. XFree86 does not support this, and very few PC graphics cards have the hardware to make this work. Some workstations, SGI boxes especially, have multiple color look up tables. This more usually has an effect when running in 8bpp, but it is possible that the unnamed application is trying to access mutually independent color look up tables. Pc Graphics hardware can not support more than a single 8 bit color look up table (which is why SGI boxes and some other workstations have less colormap flashing). There are a few chips that would help, which could be used on a PC graphics board, but they are expensive and used only by specialist board makers for unusual market segments. Are you sure that the application is not attempting to use SGI's DGL or SGI OpenGL's GLX? Depending upon where the error message is being generated, this might be the cause. Are you sure that the application requires 24 bit color? When running the application on the SGI box, displaying to the SGI display, use 'xwininfo' to find the color depth(s) of the applications windows. A message about running out of colors in a colormap suggests that the application is assuming the presence of a programmable colormap. This is normally only true in lower color depths (e.g. you get 8bpp PseudoColor Visuals, but 24bpp Pseudocolor Visuals are unknown as they'd need 48MB of high speed color look up table memory for the DAC; when most graphics board vendors are happy with 16MB of display memory, that would be rather unusual and expensive). > i'm running in 32 bit color depth, and no color intensive processes > are being displayed. (don't tell me that sgi has invented 64-bit > color...right?) what does this mean? You are not actually running in 32 bit color depth. You are running in 24 bit color depth and using 32 bits to do it. 8 bits are being wasted. There are some real 32 bit color depth representations, such as using "RGBA" formats, but PC's don't do those. The nomenclature problem arises because Intel processors are particularly sensitive to word alignment. If you read a word and it is not aligned with a word boundary then you significantly decrease access. This is also trus to a greater or lesser extent for other processors, too. The color hardware uses 8 bits for each of the red, Green and Blue color guns in the tube. You therefore need 24 bits of color data. This would result in two in three data accesses being misaligned, if data were represented in system memory in contiguous 24 bit chunks. The consequence is an approximate 15% speed penalty. By "wasting" one byte for each pixel and aligning on a word boundary the speed penalty is removed, at the cost of an approximate 25% memory increase for each dynamically allocated graphical representation. However, it is possible to use 32 bits to store the 24 bit in system memory (accessible directly o the application) but to represent the data in packed form on the system bus and in the graphics board. Accelerated-X does this, which is one reason why our packed pixel representation does not cause application problems, but we still get the full 25% speed up that you'd expect from the better bandwidth utilisation. For some reason, XFree86 appear to have done the right thing in some variants of their Servers, but seem to have lost or forgotten the knowledge in the XFree86_SVGA Server for the Matrox Millennnium type boards. Although the XFree86 Server gains the 25% bus speed up, it then loses about 15% in systm memory access times, for a total speed up of only 10% or so. This is part of the reason that their Servers benchmark at about 50% of our speed. The real problem that using a 24 bit system representation causes is that application developers do not expect this format. Workstation developers use a 32 but system memory representation. All previous X Servers, including earlier XFree86 Server, use 32 bit system representation, instead of the bizarre form introduced last year by XFree86. Since it is a largely untestable format, as well as being rather unwise for maximum speed, I expect that quite a few applications will have unexpected problems. This is *not* a consequence of 24 bit packed pixel operation, but a consequence of presenting 24 bit packed pixels to the application. You could equally easily cause the same problem by using 24 bit packed representation to applications and then unpacking the data for the bus transfer and in the graphics board memory. Anyway, workstations represent their 24 bit color data data using 32 bits. It is only PC's, only since 1994, that use packed pixel representation. So if you use a 32 bit system representation with XFree86, you are less likely to trigger application problems than if you use 24 bit system representation. -- Jeremy Chatfield, Xi Graphics mailto:[EMAIL PROTECTED] tel:+44(0)1234.710030 Commercial X Products: Servers, CDE, contracts and custom development http://www.xig.com ftp://ftp.xig.com/ mailto:[EMAIL PROTECTED] tel:+1.303.298.7478 fax:+1.303.298.1406 mailto:[EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature