Re: Color question (answer is not device,decomposed=0)

["Liam Gumley" <Liam.Gumley(at)ssec.wisc.edu>]

Troy Carter <tcarter@pppl.gov> wrote in message
Pine.LNX.4.21.0004242329340.29603-100000@russell.pppl.gov">news:Pine.LNX.4.21.0004242329340.29603-100000@russell.pppl.gov...
>
> On Mon, 24 Apr 2000, Liam Gumley wrote:
>
> > upgrade to XFree86 version 4 is in order). In addition, I believe that
IDL
> > does *not* support X displays in 16 bpp mode; it only supports 8-bit or
> > 24-bit bpp.
>
> IDL runs fine on a 16 bit display.  I do it every day -- in 5.2, it took a
> little trickery (I had to set device,pseudo=8,decomposed=0).  But in 5.3
> it starts right up.  Yes I am sure the terminal is 16 bit.  Perhaps IDL
> effectively runs in 8 bit mode, so perhaps I don't use the 16 bit
> capability, but the point is that I don't have to run in lower color depth
> to get idl to work.

The distinction here is that although IDL will *run* in 16-bit mode, it does
not explicitly support 16-bit mode for Direct Graphics on UNIX platforms (as
it does on Windows platforms for example). See my previous reference to IDL
Tech Tips for the RSI position on this issue.

> > The bottom line:
> > (1) If you want to get IDL running and do some work, then re-configure
your
> > Linux X-server to start in 8 bpp.
> > (2) If you want to tinker with the X-server, try an upgrade to XFree86
4.0
>
> I don't think it is necessary to run in 8bpp mode.  24bit mode works
> great, I have been using it for 1.5 years (linux workstation running idl
> session on solaris box).  I have just run into one issue when trying to
> migrate to Object graphics.  I think that instead of giving up on 24-bit
> mode I should try to solve the problem and perhaps uncover a bug in IDL or
> XFree86...  Who the heck works with 8bit displays anymore anyway!? ;)

If 24-bit mode seems to work fine, then by all means go with it. However I
think you would be surprised by the number of people who work in 8-bit mode
exclusively (I'm not one of them).

> About my particular problem, after some very helpful comments from several
> people (by e-mail mostly), it seems that the problem is due to byte-order
> swapping as the solaris box sends graphics to my x-server.  It only
> effects the IDLgrView object -- other objects (plots, axes, text,
> polygons) all render with the correct colors.  For this reason, it is
> possible that it is a bug in IDL (problems with dithering or with the
> Mesa libs have been suggested).  Thanks to everyone who commented on the
> problem (Randall, Rick, kschultz).  When it is completely resolved, I will
> write again to the news group.

The byte-swapping theory sounds interesting. If you can reproduce this
behavior and RSI verifies the bug report, by all means let us know. You
might want to see if you can reproduce the behavior on another Linux host
which is running a different X-server.

I suppose it's time for me to get back in the game and upgrade my trusty
Thinkpad from Redhat 5.0 and IDL 5.1.

Cheers,
Liam.