How to handle read/write colormap without messing up everybody else - Xwindows

This is a discussion on How to handle read/write colormap without messing up everybody else - Xwindows ; I'm having to fix a very old application that, in my opinion, was written quite poorly. I will have time to rewrite it eventually, but now it's "just fix it fast!" The program chooses to use a read/write colormap, allocating ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: How to handle read/write colormap without messing up everybody else

  1. How to handle read/write colormap without messing up everybody else

    I'm having to fix a very old application that, in my opinion, was
    written quite poorly. I will have time to rewrite it eventually, but
    now it's "just fix it fast!"

    The program chooses to use a read/write colormap, allocating 64 pixels
    to play with. In the one usage I've seen of it, it's fed the color
    values first, then the pixels are drawn. The protocol it uses to talk
    to other, currently unknown, parts of the system, though, allow for
    color values to change after drawing, which may be why it's using read/
    write colors. (Either that or the guys who wrote it back in the 90's
    didn't know what they were doing ... which is a quite likely
    situation.)

    Anyhow, on most of the graphics cards we've supported over the years,
    all works well; the window shows up and the graphics get drawn into
    it, without messing up any other colors. These video cards allow at
    least 2 colormaps installed at a time.

    Then we moved to a Radeon 7500, which allows one and only one colormap
    installed at a time. The result is that the program, when run, turns
    the entire screen black, making the control program(s) unusable.

    My fallback position is to special-case this one condition and force
    read-only colorcell usage, hoping that the other parts of the system
    don't take advantage of the read/write colorcells for animation.

    Is there a way I can make a read/write copy of the default read-only
    colormap, but have some elbow room for the pixel values I need to use?

  2. Re: How to handle read/write colormap without messing up everybodyelse

    On Jan 22, 6:38*am, Joe Sewell wrote:
    > I'm having to fix a very old application that, in my opinion, was
    > written quite poorly. I will have time to rewrite it eventually, but
    > now it's "just fix it fast!"
    >
    > The program chooses to use a read/write colormap, allocating 64 pixels
    > to play with. In the one usage I've seen of it, it's fed the color
    > values first, then the pixels are drawn. The protocol it uses to talk
    > to other, currently unknown, parts of the system, though, allow for
    > color values to change after drawing, which may be why it's using read/
    > write colors. (Either that or the guys who wrote it back in the 90's
    > didn't know what they were doing ... which is a quite likely
    > situation.)
    >
    > Anyhow, on most of the graphics cards we've supported over the years,
    > all works well; the window shows up and the graphics get drawn into
    > it, without messing up any other colors. These video cards allow at
    > least 2 colormaps installed at a time.
    >
    > Then we moved to a Radeon 7500, which allows one and only one colormap
    > installed at a time. The result is that the program, when run, turns
    > the entire screen black, making the control program(s) unusable.


    Almost all screens allow only one colormap at a time.

    When the cursor is outside any of your program's windows, the default
    colormap should be restores for all other apps (but your program
    will now have "random" colors showing).

    >
    > My fallback position is to special-case this one condition and force
    > read-only colorcell usage, hoping that the other parts of the system
    > don't take advantage of the read/write colorcells for animation.
    >
    > Is there a way I can make a read/write copy of the default read-only
    > colormap, but have some elbow room for the pixel values I need to use?


    Use xdpyinfo to determine what visuals your screen supports, and
    what the default visual is.

    If you have to use a private colormap, try allocating pixels starting
    at
    high pixel values rather than low.

    --
    Fred Kleinschmidt

  3. Re: How to handle read/write colormap without messing up everybodyelse

    On Jan 22, 3:56*pm, fred.l.kleinschm...@boeing.com wrote:
    > On Jan 22, 6:38*am, Joe Sewell wrote:
    >
    >
    >
    >
    >
    > > I'm having to fix a very old application that, in my opinion, was
    > > written quite poorly. I will have time to rewrite it eventually, but
    > > now it's "just fix it fast!"

    >
    > > The program chooses to use a read/write colormap, allocating 64 pixels
    > > to play with. In the one usage I've seen of it, it's fed the color
    > > values first, then the pixels are drawn. The protocol it uses to talk
    > > to other, currently unknown, parts of the system, though, allow for
    > > color values to change after drawing, which may be why it's using read/
    > > write colors. (Either that or the guys who wrote it back in the 90's
    > > didn't know what they were doing ... which is a quite likely
    > > situation.)

    >
    > > Anyhow, on most of the graphics cards we've supported over the years,
    > > all works well; the window shows up and the graphics get drawn into
    > > it, without messing up any other colors. These video cards allow at
    > > least 2 colormaps installed at a time.

    >
    > > Then we moved to a Radeon 7500, which allows one and only one colormap
    > > installed at a time. The result is that the program, when run, turns
    > > the entire screen black, making the control program(s) unusable.

    >
    > Almost all screens allow only one colormap at a time.
    >
    > When the cursor is outside any of your program's windows, the default
    > colormap should be restores for all other apps (but your program
    > will now have "random" colors showing).


    The previous hardware allowed a mininum of 2, maximum of 8 or 9
    colormaps installed, thus avoiding this issue. The particular
    application is drawing to a window separate from the "control" window
    (which is a terminal window). Thus avoiding "technicolor" would be a
    plus.

    > > My fallback position is to special-case this one condition and force
    > > read-only colorcell usage, hoping that the other parts of the system
    > > don't take advantage of the read/write colorcells for animation.

    >
    > > Is there a way I can make a read/write copy of the default read-only
    > > colormap, but have some elbow room for the pixel values I need to use?

    >
    > Use xdpyinfo to determine what visuals your screen supports, and
    > what the default visual is.


    Done and done. The default is 24-plane TrueColor (i.e., read-only
    colorcells). There are numerous apparently duplicate visuals
    supported, but the only one that is different is that it does support
    24-bit DirectColor.

    > If you have to use a private colormap, try allocating pixels starting
    > at
    > high pixel values rather than low.


    Since the default visual is 24-plane TrueColor, the pixel values for
    much of the screen are already high (since they wind up mapping to the
    RGB value directly).

    It turned out nobody was taking advantage of the read/write color
    capability, so I'm safe.

+ Reply to Thread