Re: Colormap Issue with Gtk99.3

[Owen Taylor <owt1 cornell edu>]

Federico Mena <federico@nuclecu.unam.mx> writes:

> >  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

I'm pretty sure that wasn't the case for the reported problem -
it was a TrueColor visual for one thing. GTK won't really
handle the above right - it will only see the first 256 entries
for some things (but it won't crash anymore). The problem
is the way the GdkColorMap and GdkColorMapPrivate are set
up. But I don't think 12 plane PseudoColor is in use very
often.

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

The Apple II-GS, IIRC, had lookup tables with 12-bit (4-4-4) entries.
The colormap had a fairly small number of entries, but you could
hook into the horizontal refresh interrupt and change colormaps
on the fly, allowing you to get most of the 4096 colors onscreen,
just not on the same row...

> >  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.

My (S3, xf86svga) server lists all sorts of funky visuals in 8
bit mode, including 3/3/2 TrueColor and DirectColor.

I really should try pointing GTK at some of them and watching the
fun...

                                        Owen