| TVRD() with 1024 x 1024 window: IDL or MacX 1.5 problem? [message #5506] |
Wed, 17 January 1996 00:00  |
joseph.b.gurman
Messages: 15
Registered: October 1995
|
Junior Member |
|
|
I'm using IDL 4.0.1a on a DEC Alpha running OpenVMS, and using a
PowerMac 9500/132 with a PCI display card at 1200 x 1600 resolution to be
able to display 1024 x 1024 images without chopping off the top 46 rows
(take a look at !d.y_vsize on a ysize = 1024 window on a 1024 x 1280
display). Everything works OK except for TVRD --- either with explicit
arguments or just as TVRD(), it messes up the read-back image
significantly.
Has anybody else with a large display seen this sort of problem, or am
I simply guilty of the ultimate crime of the '90's: not using an OS whose
name begins with either Windows or th eletter "u?"
Actually, I'm willing to believe it's Apple's Open Transport 1.0.8, or
their Ethernet driver from all the horror stories I've heard, but I'd be
interested in any other stories.
Thanks,
Joe Gurman
--
J.B. Gurman / Solar Physics Branch/ NASA Goddard Space Flight Center/
Greenbelt MD 20771 USA / joseph.b.gurman@gsfc.nasa.gov
| Federal employees are still prohibited from holding opinions while at |
| work. Therefore, any opinions expressed herein are somebody else's. |
|
|
|
|
| Re: TVRD() with 1024 x 1024 window: IDL or MacX 1.5 problem? [message #5625 is a reply to message #5506] |
Fri, 19 January 1996 00:00  |
David S. Foster/Admin
Messages: 14
Registered: May 1995
|
Junior Member |
|
|
joseph.b.gurman@gsfc.nasa.gov (Joseph B. Gurman) wrote:
>
> I'm using IDL 4.0.1a on a DEC Alpha running OpenVMS, and using a
> PowerMac 9500/132 with a PCI display card at 1200 x 1600 resolution to be
> able to display 1024 x 1024 images without chopping off the top 46 rows
> (take a look at !d.y_vsize on a ysize = 1024 window on a 1024 x 1280
> display). Everything works OK except for TVRD --- either with explicit
> arguments or just as TVRD(), it messes up the read-back image
> significantly.
>
We have had a very similar problem with TVRD() under Solaris 2.3 .
RSI tech support verified that there were problems with the TVRD()
function. Specifically, our problem was due to TVRD's failure to
read correctly from scrollable draw widgets. RSI's answer was that
if there are regions of the canvas that are not "onscreen" (due to
scrolling, being behind another window, or being iconified), those
portions of the array can get screwed up.
They suggested playing around with backing store, as some systems
will supply it and some will not. Your window is so large that
perhaps your server is refusing. You might try forcing IDL to
provide backing-store using the RETAIN=2 keyword when you create
the draw widget.
I know that on our system this did not help, but in your case it
might do the trick. We never did get TVRD() to work properly
with scrollable draws (IDL 4.0.1), so I wrote the following
little work-around that works fine for us. Your window is so
large that performance might be an issue here.
; SAFE_TVRD.PRO 9-25-95
;
; This function is a safer version of IDL's TVRD() function. First,
; there was a bug related to the reading from a scrollable draw. Also,
; the TVRD() function uses an X routine that has problems if the
; window is obscured or iconized. This routine uses the DEVICE, COPY=
; command to first copy the window contents to a new window pixmap,
; and then reads from this pixmap into the array.
FUNCTION safe_tvrd, draw_widget, xsize, ysize
on_error, 2
old_window = !d.window
window, xsize=xsize, ysize=ysize, /free, /pixmap ; Create new window
widget_control, draw_widget, get_value=window
device, copy=[0,0, xsize,ysize, 0,0, window] ; Copy into new window
image = tvrd() ; Read into array
wdelete, !d.window
if (old_window ne -1) then wset, old_window
return, image
END
Hope this helps. We've never had problems with TVRD() reading from
a pixmap window.
David Foster
UCSD Brain Image Analysis Lab
foster@bial1.ucsd.edu
|
|
|
|
| Re: TVRD() with 1024 x 1024 window: IDL or MacX 1.5 problem? [message #5668 is a reply to message #5506] |
Sun, 28 January 1996 00:00 |
joseph.b.gurman
Messages: 15
Registered: October 1995
|
Junior Member |
|
|
In article <4dos29$ebk@news1.ucsd.edu>, David Foster
<foster@bial6.ucsd.edu> wrote:
> joseph.b.gurman@gsfc.nasa.gov (Joseph B. Gurman) wrote:
>>
>> I'm using IDL 4.0.1a on a DEC Alpha running OpenVMS, and using a
>> PowerMac 9500/132 with a PCI display card at 1200 x 1600 resolution to be
>> able to display 1024 x 1024 images without chopping off the top 46 rows
>> (take a look at !d.y_vsize on a ysize = 1024 window on a 1024 x 1280
>> display). Everything works OK except for TVRD --- either with explicit
>> arguments or just as TVRD(), it messes up the read-back image
>> significantly.
>>
>
> We have had a very similar problem with TVRD() under Solaris 2.3 .
> RSI tech support verified that there were problems with the TVRD()
> function. Specifically, our problem was due to TVRD's failure to
> read correctly from scrollable draw widgets. RSI's answer was that
> if there are regions of the canvas that are not "onscreen" (due to
> scrolling, being behind another window, or being iconified), those
> portions of the array can get screwed up.
>
> They suggested playing around with backing store, as some systems
> will supply it and some will not. Your window is so large that
> perhaps your server is refusing. You might try forcing IDL to
> provide backing-store using the RETAIN=2 keyword when you create
> the draw widget.
>
> I know that on our system this did not help, but in your case it
> might do the trick. We never did get TVRD() to work properly
> with scrollable draws (IDL 4.0.1), so I wrote the following
> little work-around that works fine for us. Your window is so
> large that performance might be an issue here.
>
>
> ; SAFE_TVRD.PRO 9-25-95
> ;
> ; This function is a safer version of IDL's TVRD() function. First,
> ; there was a bug related to the reading from a scrollable draw. Also,
> ; the TVRD() function uses an X routine that has problems if the
> ; window is obscured or iconized. This routine uses the DEVICE, COPY=
> ; command to first copy the window contents to a new window pixmap,
> ; and then reads from this pixmap into the array.
>
> FUNCTION safe_tvrd, draw_widget, xsize, ysize
>
> on_error, 2
>
> old_window = !d.window
> window, xsize=xsize, ysize=ysize, /free, /pixmap ; Create new window
>
> widget_control, draw_widget, get_value=window
> device, copy=[0,0, xsize,ysize, 0,0, window] ; Copy into new window
>
> image = tvrd() ; Read into array
> wdelete, !d.window
> if (old_window ne -1) then wset, old_window
>
> return, image
> END
>
>
David -
Many thanks to you and others for your suggestions. As it turns out,
however,
neither RETAIN = 2 nor pixmap copying (nor the combination), nor (as some others
have suggested) making certain the graphics window is uncovered by any other
windows has any effect. Time to ping RSI.
Thanks again to all who responded,
Joe Gurman
--
| Joseph B. Gurman / NASA Goddard Space Flight Center / Solar Data Analysis| | Center/ Code 682.3 / (301) 286-4767 / joseph.b.gurman@gsfc.nasa.gov |
| (This .sig line declared non-emergency.) |
| "Excepted" = employed but unpaid. Wonder if my kids can eat that? |
|
|
|
|
| Re: TVRD() with 1024 x 1024 window: IDL or MacX 1.5 problem? [message #5697 is a reply to message #5506] |
Tue, 23 January 1996 00:00 |
Andrew Cool
Messages: 219
Registered: January 1996
|
Senior Member |
|
|
joseph.b.gurman@gsfc.nasa.gov (Joseph B. Gurman) wrote:
> I'm using IDL 4.0.1a on a DEC Alpha running OpenVMS, and using a
> PowerMac 9500/132 with a PCI display card at 1200 x 1600 resolution to be
> able to display 1024 x 1024 images without chopping off the top 46 rows
> (take a look at !d.y_vsize on a ysize = 1024 window on a 1024 x 1280
> display). Everything works OK except for TVRD --- either with explicit
> arguments or just as TVRD(), it messes up the read-back image
> significantly.
>
Good morning. We too use Alphas and good ol' VMS.
Now with a little fiddling, I can get a draw widget that displays a
full 1280 by 1024 array, checked by setting the outer cell along each
side to a unique colour.
You may not need your Mac now, in which case you can send it to me 8^)
Try this:-
a. from the Desktop Workspace menu, set the border width to OTHER, and
set the OTHER width to 0
b. Also click OFF the Resize and Window border options under Border
decorations.
c. Save the Wm settings and restart the WM.
d. Try this code
;----------------------------------------------------------- -------------
PRO TEST_EVENT.ev
common data,z
type = tag_names(ev,/st)
if type EQ 'WIDGET_TIMER' THEN BEGIN
widget_control,ev.top,/destroy
return
endif
widget_control,ev.top,get_uvalue=uv
case uv of
'draw' : BEGIN
IF ev.type EQ 0 THEN BEGIN
IF ev.press EQ 2 THEN BEGIN
widget_control,ev.top,/icon
ENDIF
IF ev.press EQ 4 THEN BEGIN
widget_control,ev.top,/DESTROY
ENDIF
ENDIF
IF ev.type EQ 1 THEN BEGIN
IF ev.press EQ 0 THEN BEGIN
erase & tvscl,z
ENDIF
ENDIF
END
ELSE :
ENDCASE
END
PRO TEST
common data,z
z = lonarr(1280,1024)
; set up a cooured edge around the array
z(*,0) = 219
z(*,1023) = 219
z(0,*)=219
z(1023,*)=219
x = widget_base(TLB_FRAME_ATTR=4)
y=widget_draw(x,xs=1280,ys=1024,/BUTTON)
widget_control,x,/real
loadct,13
!P.BACKGROUND=100
erase
widget_control,x,timer=30
xmanager,'test',x
END
;----------------------------------------------------------- ------------
Now I hope I've typed that in correctly from our secure network!
What should happen:
a. A full screen window with NO borders at all
b. This will self destruct after 30 seconds, in case there's an error
in your code, and you're left with this giant window obscuring
everything else!
c. Mouse button 1 will erase the window, and draw the array z, which
should leave a distinct coloured border, 1 pixel wide, around
the window.
d. Mouse 2 should iconise the window
e. Mouse button 3 should destroy the widgets.
Note : I'm not sure what colour the border will be on your system.
we routinely limit the total colours to 220.
This may not be of any use, but it was interesting to see that it could
be done...
Cheers,
Andrew Cool
------------------------------------------------------------ -------------
Andrew Cool
|andrew.cool@dsto.defence.gov.au
High Frequency Radar Division |phone : +61 8 259 5740
Defence Science & Technology Organisation | fax : +61 8 259 6673
PO Box 1500 Salisbury, South Australia, 5108 |
------------------------------------------------------------ -------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
