From: gatech!mit-eddie!Alliant.COM!abel@unmvax.cs.unm.edu (Doug Abel)
Newsgroups: comp.soft-sys.khoros
Subject: Re: 24-bit questions...
Date: 10 Apr 92 00:07:08 GMT
Article-I.D.: pprg.37378



Hi Steve,
	I have been working on a similar problem with editimage and 
    24-bit DirectColor visuals.  I'm sure Mark Young will me able to answer
    you with greater depth and detail, but in the event that he is busy, I 
    think I can help you a bit.

>> 
>> I've been trying to track down a problem with 'editimage' on a DG AViiON
>> with a 24-bit display.  Briefly, 'putimage' easily displays 24-bit images
>> with Patch5, but 'editimage' turns into a nifty little 'kill the server'
>> command...

   This sounds like a bug in your server to me. editimage comes up fine
   using our 24-bit DirectColor visual, and I don't think your server should die
   regardless of what bad things a client does.  At worst, you should get
   an X protocol error.

>> 
>> I think the problem is with a BAD ACCESS in XStoreColors().  I note
>> that the code in ~khoros/src/Lib/xvdisplay/update.c tests to see
>> if the display is read_only, and if so, doesn't call XStoreColors().
>> 
>> However, the code in ~khoros/src/xvroutines/editimage/utils.c doesn't
>> bother to check the 'read_only' status and just calls XStoreColors().
>> 
   editimage is looking for a writable colormap, so that the user can play
   with the nifty display utilities that are a part of editimage.
   And DirectColor visual should be writable.  So you should not get a 
   bad access when attempting to store colors to this visual.


   Once editimage is up using a DirectColor visual, you will still have
   problems with 24-bit images.  I think this is because editimage
   does not currently fully support 24-image depths.

   Some problems I encountered with the display utilities were:

   Image Zoom:  
	This will generate a BAD MATCH protocol error due to XPutImage
	attempting to load a 24-bit subimage on an 8-bit parent window.

   Pseudo Color:
	This diddles with the Pseudo Lut, typically
        at some other depth than 24.  So you will not be changing the
	LUT locations that your picture is actually displaying from.

   Interactive LUT:
	Once again, this plays with the wrong LUT.

   From looking at the code, it is clear that the KHOROS group has not had
   time to fully support 24-bit images in editimage.  I believe Mark has
   already commented a bit on this.


   There is another nasty side-effect with having a 24-bit DirectColor
   visual, and that is utilities like putimage could potentially get
   this as a their visual, and thus multiple putimages on a screen will
   end up with their own unique colormaps.  On our system this means
   a lot of technicolor flashing as you move from one window to another.
   The reason for this is that KHOROS currently looks for the deepest
   visual it can find to suit it's needs.  (See xdisplay.c in libdisplay.a)

    I have modified this code somewhat to prioritize the search through
    the available system visuals, and this alleviates the flashing for
    utilities that only need read-only colormaps.  It also takes care
    of ensuring that utilities that need writable colormaps only get
    PseudoColor visual types.  This allows editimage to function properly.

    If you or any other person would like a copy of these changes I will
    post them.  Mark Young could probably bless it or modify it as he sees
    fit.

				-doug ( abel@Alliant.COM )