Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Grady Daub (gadZOOKS8371@garnet.acns.fsuMMER.edu) writes: > Sometimes I use Exceed to run a Common Desktop Environment on an IBM > type computer. (Pentiums and all that.) After a while, I discovered that > I had to type > > DEVICE, DECOMPOSE=0 > > for the colors to work. (Thanks to RSI for letting me discover that > while searching their site for something else and for RSI tech. support > for not realizing that that was the solution to my problem.) What!? Don't those folks read this newsgroup? That is the answer to 95% of the problems that have the word "color" in their descriptions! :-) > Now, I've a new problem. > The problem is that,while using exceed, the colors don't cycle > on-screen. The displayed picture (or, say, XLOADCT) colors stay the > same. You have to reload the picture to see the final outcome of the > palette change. The answer to the other 5% of the color questions is "that is how 24-bit color works". Here are some articles you might want to read: http://www.dfanning.com/documents/tips.html#UsingColors Specifically, be sure you read these: http://www.dfanning.com/tips/colors24.html http://www.dfanning.com/tips/noxloadct.html http://www.dfanning.com/tips/image24_colors.html The kind of information you have been asking about lately is covered in *extensive* detail in my book. If you are a student, you might be interested in one of my "student discounted books". I got some books back from Amazon this weekend, whose covers had been damaged in shipment. (More likely in *unpacking* the shipment, but they are selling so many books for me, I'm not inclined to complain.) In any case, these books don't look so good on the outside, but they save you *months* of aggravation on the inside. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
Liam Gumley wrote: > > Barry Latter wrote: >> I've had problems with window buffering using Exceed on a PC for >> displaying IDL plots. Basically, if a window is opened in front of an >> IDL graphics window, the IDL window is blanked out when it's brought >> back to the front. Is this an IDL or Exceed problem? Has anyone found a >> way around it? > > Issuing the following command at the start of your IDL session should do > the trick: > > DEVICE, DECOMPOSED=0, RETAIN=2 > FWIW, this has never worked for me, in that curves drawn in the work area are not retained with retain=2 (or anything else). Here is the device info, if it helps: IDL> help, /device Available Graphics Devices: CGM HP LJ NULL PCL PRINTER PS REGIS TEK X Z Current graphics device: X Server: X11.0, Sun Microsystems, Inc., Release 3600 Display Depth, Size: 8 bits, (1152,900) Visual Class: PseudoColor (3) Bits Per RGB: 8 Physical Color Map Entries (Used / Total): 256 / 256 Colormap: Private, 256 colors. Translation table: Enabled Graphics pixels: Combined, Dither Method: Ordered Write Mask: 255 (decimal) ff (hex) Graphics Function: 3 (copy) Current Font: <default>, Current TrueType Font: <default> Default Backing Store: Pixmap. thx, bkr
Grady Daub wrote: > > Sometimes I use Exceed to run a Common Desktop Environment on an IBM > type computer. (Pentiums and all that.) After a while, I discovered that > I had to type > > DEVICE, DECOMPOSE=0 > > for the colors to work. (Thanks to RSI for letting me discover that > while searching their site for something else and for RSI tech. support > for not realizing that that was the solution to my problem.) > > Now, I've a new problem. I wrote a program that cycles the palette (and > a few other things). It would create plasma if you have a plasma-like > picture showing. (A color mandelbrot would work.) > > The problem is that,while using exceed, the colors don't cycle > on-screen. The displayed picture (or, say, XLOADCT) colors stay the > same. You have to reload the picture to see the final outcome of the > palette change. (1) Close Exceed. (2) Reset your Windows desktop to 8 bit mode (Right click on the Desktop, select Properties; Settings; Color Palette 256 colors). (3) Restart Exceed. (4) Restart IDL on the remote server. Now changes to the color table should be reflected instantly onscreen. Note that this is *only* possible in 8 bit mode. Cheers, Liam. -- Liam E. Gumley Space Science and Engineering Center, UW-Madison http://cimss.ssec.wisc.edu/~gumley
Barry Latter wrote: > I've had problems with window buffering using Exceed on a PC for > displaying IDL plots. Basically, if a window is opened in front of an > IDL graphics window, the IDL window is blanked out when it's brought > back to the front. Is this an IDL or Exceed problem? Has anyone found a > way around it? Issuing the following command at the start of your IDL session should do the trick: DEVICE, DECOMPOSED=0, RETAIN=2 Cheers, Liam. -- Liam E. Gumley Space Science and Engineering Center, UW-Madison http://cimss.ssec.wisc.edu/~gumley
Hi, Different question regarding Exceed and IDL I've had problems with window buffering using Exceed on a PC for displaying IDL plots. Basically, if a window is opened in front of an IDL graphics window, the IDL window is blanked out when it's brought back to the front. Is this an IDL or Exceed problem? Has anyone found a way around it? Any help appreciated! Baz Department of Meteorology Reading University
Mark Hadfield (m.hadfield@niwa.cri.nz) writes: >> (1) You are using object graphics in the window, in which >> case RETAIN should *always* be set to 0. > > I disagree. For object graphics draw widgets on Windows NT, I have found the > best results (fast drawing, fast refresh when a window is re-exposed) are > achieved with: > > RENDERER = 0 ; "Hardware" renderer > RETAIN=2 ; IDL provides backing store > EXPOSE_EVENTS=0 ; Not necessary for widget application to redraw its > own windows > > I imagine that other platforms have different optimum settings, but you use > NT primarily, don't you David? When objects first came out I noticed that my axes labels would disappear. After about 50 frustrating hours convincing myself that I was doing everything correctly, I gave up and contacted RSI. I was told in no uncertain terms that this was caused by setting the RETAIN keyword to 2 and that RETAIN should *always* be 0 in object graphics. This made sense, because you already *have* the backing store to repair the window: the view you want to display. Why carry around yet more baggage? Sure enough, it fixed the problem. I was so scarred by this experience that I have just been plodding along doing it this way from that moment forward. Frankly, I'm shocked to hear there is another way. :-) With respect to rendering. I spent a pile of dough getting two really nice 3D graphics cards that had OpenGL support. *Both* of those cards render slower in hardware than they do in software, although I have never tried setting the RENDERER keyword on the draw widget. I just always set the Hardware Rendering option in the Option Settings. Of course, this is one of those situations where *nobody* in technical support, from *either* company, wants to have anything to do with you. It's always *their* fault. Let's just say I *knew* I should have bought the Dell machine. :-( Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
Here's a few other values/settings > that I've learned not to take for granted when an application runs (i.e. > I don't assume any particular value). > > (1) DEVICE keywords: > RETAIN > DECOMPOSED > SET_CHARACTER_SIZE > > (2) System variables: > !ORDER (order for displaying images) > !D.TABLE_SIZE (size of the color table) > !D.N_COLORS (number of colors available) > !D.NAME (name of the current display device) > !D.WINDOW (index of the current graphics window) > > (3) Widget appearance: > WIDGET_CONTROL keyword DEFAULT_FONT > > Anyone else care to add to the list? > I have been clobbered by using canned routines that set !P. !X, !Y, !Z system variables for their plots. Then, when I am in the same session and try my own interactive stuff, these stale values remain. I should write a routine that I can call that cleans the slate of all set variables and restores them to the defaults -- has someone done this already? Dick French
David Fanning wrote: > Several obtuse reasons for setting RETAIN=0 in a draw widget > come immediately to mind: > > (1) You are using object graphics in the window, in which > case RETAIN should *always* be set to 0. > > (2) You know how screwy colors can be and you wish to > protect the colors associated with this application > by "restoring" your colors every time the widget is > exposed. David points out some good reasons why an IDL programmer should not assume a particular value for RETAIN. Here's a few other values/settings that I've learned not to take for granted when an application runs (i.e. I don't assume any particular value). (1) DEVICE keywords: RETAIN DECOMPOSED SET_CHARACTER_SIZE (2) System variables: !ORDER (order for displaying images) !D.TABLE_SIZE (size of the color table) !D.N_COLORS (number of colors available) !D.NAME (name of the current display device) !D.WINDOW (index of the current graphics window) (3) Widget appearance: WIDGET_CONTROL keyword DEFAULT_FONT Anyone else care to add to the list? Cheers, Liam. -- Liam E. Gumley Space Science and Engineering Center, UW-Madison http://cimss.ssec.wisc.edu/~gumley
bkrrrrr (beaker@llama.pilz.cack) writes: > I copied your script to idl_startup.pro, and saw it > run at startup. However, I then found the problem is actually > caused by the person who wrote the program setting retain=0 when > calling WIDGET_DRAW for some obtuse reason. grrrrr... Several obtuse reasons for setting RETAIN=0 in a draw widget come immediately to mind: (1) You are using object graphics in the window, in which case RETAIN should *always* be set to 0. (2) You know how screwy colors can be and you wish to protect the colors associated with this application by "restoring" your colors every time the widget is exposed. Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
Liam Gumley wrote: > > bkrrrrr wrote: >>> Issuing the following command at the start of your IDL session should do >>> the trick: >>> >>> DEVICE, DECOMPOSED=0, RETAIN=2 >>> >> FWIW, this has never worked for me, in that >> curves drawn in the work area are not retained >> with retain=2 (or anything else). > > Strange. Did you issue the command > > DEVICE, RETAIN=2 [snip] I copied your script to idl_startup.pro, and saw it run at startup. However, I then found the problem is actually caused by the person who wrote the program setting retain=0 when calling WIDGET_DRAW for some obtuse reason. grrrrr... thx, bkr
bkrrrrr wrote: >> Issuing the following command at the start of your IDL session should do >> the trick: >> >> DEVICE, DECOMPOSED=0, RETAIN=2 >> > FWIW, this has never worked for me, in that > curves drawn in the work area are not retained > with retain=2 (or anything else). Strange. Did you issue the command DEVICE, RETAIN=2 *before* creating any graphics windows, just after starting IDL? This command *must* be executed prior to creating a graphics window, otherwise it will have no effect (at least it has no effect on my SGI box running IDL 5.2). I recommend using this command in a startup file. For example, all our local IDL users have the following startup file (named idl_startup.pro): ;---cut here--- ;- Set up 8 bit display and grab colors if !version.os_family eq 'unix' then device, pseudo = 8 device, retain = 2, decomposed = 0 window, /free, /pixmap, colors = -5 plot, [ 0 ] wdelete, !d.window print, 'Color table size is ', !d.table_size ;- Set graphics and widget font sizes device, set_character_size = [ 6, 9 ] widget_control, default_font = '7x13' ;- ensure IDL 5.0 XMANAGER behavior is consistent with IDL 4.0 xmanager, catch = 0 ;---cut here--- Then use the system variable IDL_STARTUP to point to the full path and name of the startup file e.g. setenv IDL_STARTUP $HOME/idl_startup.pro (C shell) export IDL_STARTUP=$HOME/idl_startup.pro (Korn shell) This code will be executed every time you start a new IDL session, and it should give you a consistent well-behaved 8 bit IDL display on all Unix platforms (as long as your Unix desktop is set to 8 bit or 24 bit mode: if you use a 16 bit or 32 bit desktop, all bets are off). Cheers, Liam. PS: Let me know if this does not work. -- Liam E. Gumley Space Science and Engineering Center, UW-Madison http://cimss.ssec.wisc.edu/~gumley
In article <7m142h$474$1@clam.niwa.cri.nz>, "Mark Hadfield" <m.hadfield@niwa.cri.nz> writes: > Richard G. French <rfrench@wellesley.edu> wrote in message > news:3783A3A3.233D8535@wellesley.edu... >> I have been clobbered by using canned routines that set !P. !X, !Y, !Z >> system variables for their plots. Then, when I am in the same session >> and try my own interactive stuff, these stale values remain. I should >> write a routine that I can call that cleans the slate of all set >> variables and restores them to the defaults -- has someone done this >> already? > > Take a look at the IDL Astronomy Library routine CLEANPLOT: > Or at PLVAR_KEEP, in my library. Mati Meron | "When you argue with a fool, meron@cars.uchicago.edu | chances are he is doing just the same"
Richard G. French <rfrench@wellesley.edu> wrote in message news:3783A3A3.233D8535@wellesley.edu... > I have been clobbered by using canned routines that set !P. !X, !Y, !Z > system variables for their plots. Then, when I am in the same session > and try my own interactive stuff, these stale values remain. I should > write a routine that I can call that cleans the slate of all set > variables and restores them to the defaults -- has someone done this > already? Take a look at the IDL Astronomy Library routine CLEANPLOT: http://idlastro.gsfc.nasa.gov/ftp/pro/plot/cleanplot.pro -- Mark Hadfield m.hadfield@niwa.cri.nz National Institute for Water and Atmospheric Research PO Box 14-901, Wellington, New Zealand
David Fanning <davidf@dfanning.com> wrote in message news:MPG.11ed28f44513782f989815@news.frii.com... > Several obtuse reasons for setting RETAIN=0 in a draw widget > come immediately to mind: > > (1) You are using object graphics in the window, in which > case RETAIN should *always* be set to 0. I disagree. For object graphics draw widgets on Windows NT, I have found the best results (fast drawing, fast refresh when a window is re-exposed) are achieved with: RENDERER = 0 ; "Hardware" renderer RETAIN=2 ; IDL provides backing store EXPOSE_EVENTS=0 ; Not necessary for widget application to redraw its own windows I imagine that other platforms have different optimum settings, but you use NT primarily, don't you David? -- Mark Hadfield m.hadfield@niwa.cri.nz National Institute for Water and Atmospheric Research PO Box 14-901, Wellington, New Zealand > > (2) You know how screwy colors can be and you wish to > protect the colors associated with this application > by "restoring" your colors every time the widget is > exposed. > > Cheers, > > David > > -- > David Fanning, Ph.D. > Fanning Software Consulting > Phone: 970-221-0438 E-Mail: davidf@dfanning.com > Coyote's Guide to IDL Programming: http://www.dfanning.com/ > Toll-Free IDL Book Orders: 1-888-461-0155