[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDL i/o on G4

Dirk Fabian wrote:
> In article <3AB152F6.48743F25@astro.cornell.edu>,
> JD Smith  <jdsmith@astro.cornell.edu> wrote:
> >"Dmitri A. Sergatskov" wrote:
> >
> >>
> >> >I should think a G4 titanium with OSX would be just about the fastest
> >> >laptop for running IDL available, but only if RSI is on the ball and has
> >> >a version ready when it hits prime time (sometime this summer, though
> >> >the release is next week).
> >> >
> [snip]
> >
> >I have used almost exclusively Linux IDL.  I find it very stable.  The
> >problem you refer to has to do with hardware and the free X display
> >servers, not IDL, and has been (partially) alleviated with XFree86
> >v4.0.  It's the inability to simultaneously *overlay* an 8-bit
> >pseudo-color visual on a native 24-bit Truecolor session.  Usually you
> >want to do this to accomodate a program written in a color-depth
> >specific way (yes David, it is a crime).  Overlay functionality has been
> >typical of most unix workstation video hardware for a long time, but has
> >only recently been catching on among standard PC components.  The Matrox
> >cards are a good example.

>  I haven't been keeping up with the characteristics of the new Xfree
> distributions.  Is it possible to have multiple visual classes on the
> same screen, or do I still need to start another session in 8bit mode?
> Xfree86 development seems to have nearly ground to halt over the past 2
> years, and it was my understanding that version 4 didn't end up having
> overlay capabilities despite advertisement to the contrary.  What's the
> scoop?

Hey Dirk, how's wisconsin livin'?  The idea of overlays is to have two
visual classes operating at once.  You can also start another X server
with a different visual and have it directed to the same display, with
xnest for example -- not exactly convenient, but works for almost any
hardware, I think.  

Try "xdpyinfo" for a list of visual modes available.  If all you see is
a Truecolor/Directcolor 24 bit entry, then you're out of luck.  I
believe the Matrox cards (mga driver) have the best (only?) support for
this under XF864. 

A more relevant question starts to be, how logical is it to jump through
so many hoops to keep writing and using 8-bit psuedocolor applications? 
I think we need an entirely new color model, one which takes full
advantage of the better capabilities of modern video hardware.  There
must be better ideas out there.  Device, decomposed=0 is just an interim
solution, which is actually more crippling than a pure PseudoColor
visual.  I wonder what tack other color-heavy processing software has