IDL window redirection

IDL window redirection
Try the IDL commands:
window,xs=300,ys=300

for x=0,350,10 do begin $
  map_set,/iso,/hor,/cont,/orth,/nobord,40,x &$
  empty &$
endfor
These commands plot a rotating globe. The empty command is needed to flush the graphics buffer. The plot sequence may be somewhat erratic and jerky on slow computers. More complex graphics such as images may flash as the screen updates. These problems are caused by the graphics not being completely updated as fast as the hardware refresh rate.
The animation may be smoothed (but not speeded up) by first building up the graphics in a hidden window and then copying it quickly to the screen window. The following commands sets up a hidden window and then runs the rotating globe sequence:
window,xs=300,ys=300            ; Visible window.
window,1,xs=300,ys=300,/pixmap  ; Hidden window.

for x=0,350,10 do begin $
  wset,1 &$                                       ; Work in hidden window.
  map_set,/iso,/hor,/cont,/orth,/nobord,40,x &$   ; Do graphics.
  wset,0 &$                                       ; Now set to visible window.
  device, copy=[0,0,300,300,0,0,1] &$             ; Copy contents of hidden.
endfor
The sequence may still not be perfectly smooth, but at least it should not flicker or flash.
This technique works quite well but does not generalize without some effort. Each different size window will need a different hidden window of matching size to work. All visible windows of the same size may use the same hidden window but it may not be convenient to keep track of which window to use. And resizable widows are another problem. Two new IDL routines were written to make it easy to use hidden windows. The technique used is documented below.
How the window redirection routines work
The two IDL routines are win_redirect and win_copy. These routines are very easy to use, just drop a call to win_redirect in front of the graphics commands in a routine, and a call to win_copy after the graphics commands. There is no need to modify the existing code other than those simple additions.
win_redirect is the more complicated routine since it keeps a list of hidden windows of different sizes and creates new ones when needed. The key feature of this routine is that it keeps a list of hidden windows of different sizes and when called looks for a match to the current window. The list and various related items are kept in an internal common. Ignoring some startup and extra options, the first thing this routine does is find the size of the current window. The window ID and size are also saved in the internal common. It then looks in it's internal list for a hidden window with the same size. If it finds one it saves its ID in common and sets it to be the current window, so all graphics commands operate in that window, the contents will be copied to the actual target window after all the graphics commands complete. If a matching window does not exist then one is made, replacing the oldest hidden window. A counter is incremented each time this routine is called and is used as a time to tag the last use of each hidden window, so the oldest can easily be found. If the oldest window in the list does not exist it is created to have the requested size and its ID, size, and counter value saved in the list. If it does exist it is first destroyed, then recreated with the correct size. The internal list is set to allow up to 10 different hidden windows.
win_copy is much simpler. It already has in the shared common the window ID of the target window and the window ID of the corresponding hidden window. So after checking to make sure win_redirect was called it simply does a device,copy=... from the hidden window to the target window after setting the target as the current window.
win_redirect has a few extra options. One option lists the status of all the hidden windows: how many are in use, the IDs, and sizes. Another option cleans up by deleting all the hidden windows. This is not actually necessary unless memory is tight. Finally, a more interesting option is the ability to easily turn window redirection on or off altogether. This is very useful to demonstrate the effects of redirection or for timing purposes.
Some notes
When debugging a new routine it may blow up after the win_redirect but before the win_copy. In that case the current window will be a hidden window and graphics commands will seem to not work. Use win_redirect, /status to see if this is the case.
The effects on program execution speed are not clear cut. In some cases the program may run faster, in others slower. It may depend on the X server or window server for the operating system in use.