Re: [gtk-list] Re: Colormap Issue with Gtk99.3

[Federico Mena <federico nuclecu unam mx>]

>  OK. It really looks to me like the 2048 is a bug in the server -

I don't know about that particular video card, but xdpyinfo on an SGI
Indy has a visual like this:

  visual:
    visual id:    0x27
    class:    PseudoColor
    depth:    12 planes
    available colormap entries:    4096
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits

Which makes perfect sense.  It may be similar to the old Amiga
displays, I think.

>  The X docs say
>  
>    "The color_map size member defines the number of entries available
>     in a newly created colormap. For DirectColor and TrueColor this
>     is the size of an individual pixel subfield"
>  
>  Now this isn't crystal clear, but it seems to be saying that
>  this should be 256 for an 8-8-8 32 bit mode, which is
>  what you have.

Look at these visuals:

  visual:
    visual id:    0x29
    class:    TrueColor
    depth:    12 planes
    available colormap entries:    16 per subfield
    red, green, blue masks:    0xf, 0xf0, 0xf00
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2a
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:    8 bits

The first one is TrueColor with 4 bits per channel (12 bits total), so
you have 16 static entries for each subfield (R/G/B).  If it were
DirectColor, you would be able to modify those entries, but since it's
TrueColor, you can't.

The second one is the good old 8-8-8 TrueColor visual :-)

This card also has an 8-plane TrueColor visual, which is 3/3/2 RGB.

  Quartic