Here, then, is example code for this approach: The reason to use the Z buffer is that it is the offscreen graphics buffer which, by default, stores TVRD() snapshots in color table index values rather than in RGB values.
The idea here is to build your graphics scene in the off-screen Z buffer, take a snapshot of the Z buffer "window" when the graphics scene is complete, and just call a TV of that snapshot right after every LOADCT is executed. This is particularly valid, if the graphics scene remains unchanged through LOADCT executions.
See the example code below for a complete demonstration of how to use XLOADCT's UPDATECALLBACK approach.Īpproach 2 - Build Your Graphics Scene in the 8-bit Z Buffer and Store a Snapshot Xloadct, UPDATECALLBACK='do_my_visualization', UPDATECBDATA=mydata This approach is the paradigm for programmers using XLOADCT's UPDATECALLBACK keyword, where the syntax would be: ĭo_my_visualization, mydata, COLOR=100, BACKGROUND=200
PRO do_my_visualization, data, _REF_EXTRA=_extra The '_REF_EXTRA' keyword is one way to pass through any keywords you want Such a procedure might have a prototype like this: The most efficient way to implement this would be to wrap all the graphics commands that recreate your visualization in a separate procedure. Below are the strategies you can use to get this redrawing to work optimally.Īpproach 1 - Redraw All the Relevant Graphics Commands After Every LOADCT
PLOT, SURFACE, TV, XYOUTS, etc.) can get the IDL graphics windows to use a new color table setting. Thus, on True Color monitors only an IDL drawing command (e.g. It simply instructs the windows that are using it to get all their colors from the video card's 256-element color table each time a new IDL drawing command is issued. Pseudocolor, the name IDL documentation has given to the 256-element color table model that IDL uses when a user has called " DEVICE,DECOMPOSED=0", does not change the O.S.'s color model. Thus, on a True Color display, if the color table changes, it does not affect the buffer that the video card is using for its routine cyclic repainting. Rather, for any given graphics window, it queries a buffer that is holding a 32-bit snapshot of the graphics in the state they had the last time the program explicitly called for a redraw. True Color, however, never queries the color table during a refresh.
manufacturers.įor the purposes of recoloring, Direct Color has the behavior that IDL users might recall from earlier years: the display uses values in the color table with every refresh (refreshing, by the way, is automatic and frequent on all monitors). Eventually, Direct Color developed capabilities to store and display 4,096, later 16,777,216 colors in their color tables, but, by that time True Color was becoming a more popular default model for O.S.
Older IDL users probably experienced Direct Color as the model in place when their monitors offered just 256 colors. Direct Color, which was a common default throughout the 1990's, holds color table indexes. The True Color "RGB" model, the model that has become ubiquitous as the default for modern display monitors, uses a "backing store" that holds the last known RGB values of each of the pixels in the graphics window. These color models implement one of two approaches to refreshing the coloring of the pixels on their display windows. It also provides an example demonstrating XLOADCT's somewhat complicated UPDATECALLBACK keyword and demonstrating _REF_EXTRA in practical use.Ī little background: There are two basic kinds of color models for video monitors in computer operating systems: True Color and Direct Color. This Help Article discusses various strategies the IDL Direct Graphics programmer can use to effect automatic recoloring of their current graphics window after any LOADCT or XLOADCT call. Thus, changes in the color table do not automatically impact on True Color displays. This model can use the 256-element color table for display, but it does not refresh its graphics windows based on values in that table. In fact, the change that occurred was in the operating systems and their video cards, which moved almost universally in the late 1990's to defaulting their displays to the RGB True Color model. Some such users might recall that in the past IDL was immediately updating color (true on most UNIX machines built before year 2000), and they think that IDL must have changed its functionality. IDL programmers, who are working with color tables in Direct Graphics (using the DEVICE,DECOMPOSED=0 setting), are frequently surprised that the scene on their graphics window does not change color automatically after a LOADCT or XLOADCT call.