Blinking text with immutable color maps - Motif

This is a discussion on Blinking text with immutable color maps - Motif ; We want to port a legacy application that depends on using writable color maps in 8-bit Pseudocolor visual for blinking text. Our target is to use 24-bit TrueColor - the legacy app also runs in 24-bit DirectColor but we want ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Blinking text with immutable color maps

  1. Blinking text with immutable color maps

    We want to port a legacy application that depends on using writable
    color maps in 8-bit Pseudocolor visual for blinking text. Our target
    is to use 24-bit TrueColor - the legacy app also runs in 24-bit
    DirectColor but we want to get away from requiring a writable color
    map. The writable colormap trick was a fast way to flash many items
    on the screen all at once, without having to loop through each item.

    The only suggestions I've seen with non-writable color maps are to use
    XmNforeground & background; I'm assuming this would mean looping
    through each widget to blink?

    Reasons for moving to TrueColor:

    - Some graphics boards don't provide 24-bit DirectColor visuals
    - 8-bit Pseudocolor makes for a horrible desktop
    - writeable colormap trick makes other stuff blink (undesirable)
    - system-level requirement for blinking text, despite how horrible it
    looks (remember this _is_ a legacy application)

    Any ideas appreciated.

    Cheers
    S. Austin

  2. Re: Blinking text with immutable color maps

    FullBandwidth@mindspring.com (S Austin) wrote in
    news:a4cb9930.0308020140.da2b623@posting.google.co m:

    > We want to port a legacy application that depends on using writable
    > color maps in 8-bit Pseudocolor visual for blinking text. Our target
    > is to use 24-bit TrueColor - the legacy app also runs in 24-bit
    > DirectColor but we want to get away from requiring a writable color
    > map. The writable colormap trick was a fast way to flash many items
    > on the screen all at once, without having to loop through each item.
    >
    > The only suggestions I've seen with non-writable color maps are to use
    > XmNforeground & background; I'm assuming this would mean looping
    > through each widget to blink?
    >
    > Reasons for moving to TrueColor:
    >
    > - Some graphics boards don't provide 24-bit DirectColor visuals
    > - 8-bit Pseudocolor makes for a horrible desktop
    > - writeable colormap trick makes other stuff blink (undesirable)
    > - system-level requirement for blinking text, despite how horrible it
    > looks (remember this _is_ a legacy application)
    >
    > Any ideas appreciated.
    >
    > Cheers
    > S. Austin
    >


    Hello,

    I noticed your article on usenet because I am also having a problem
    trying to port a legacy X-application to Linux that depends on using a
    writable colormap with the PsuedoColor visual with 8 bit depth. We use
    colormap modification to make objects in an XmDrawingArea blink. As you
    stated, the default visual in Linux seems to be 24-bit TrueColor. I
    tried using 24-bit DirectColor and the blinking worked fine in my
    application, but some Gnome related apps displayed strange colors under
    DirectColor. So, I'm facing the same dilemma that you mentioned: It
    seems that I must use TrueColor,
    but how do I implement blinking without having to re-draw every blinked
    object in our XmDrawingArea widget? I have looked into using a non-
    default visual for my application, DirectColor, and use TrueColor for
    the default visual. So, then I would have to create a private colormap
    using the DirectColor visual and change the visual, colormap, and depth
    of the toplevel widget in my application. I'm not really certain how to
    load the newly created private colormap, though. Also, under this
    scheme, I am concerned about color flashing because Linux only supports
    one hardware colormap. In other words, every time the mouse cursor
    crosses into my application, the software colormap (my private colormap)
    must be swapped with the hardware colormap. Thus, there is a risk that
    the other apps on the screen may display incorrect colors. Anyways, I
    was just wondering if you had come up with a solution to this problem.

    Thanks,

    Tony Rossomano

+ Reply to Thread