Why I switched to object graphics (most of the time)
posted Wed 26 Apr 2006 by Michael Galloy under IDL, Object graphicsI’m finding myself using object graphics over direct graphics more and more in my projects. My rule used to be to use direct graphics unless there was a compelling reason to use object graphics. This rule has now reversed itself, making object graphics the new default for me.
Here are the reasons which have lead to this:
- Visualization properties are persistent. So after you create a visualization, it is easy to change one property of your visualization and redraw. This is particularly nice in widget programs.
- Anti-aliased fonts.
IDLgrBufferbeats the True Color deficient Z buffer, hands down.- You want to make a 3D visualization with multiple items? In direct graphics, you can use the Z buffer to do hidden line removal, but then you are stuck in 8-bit color. Object graphics handles 3D graphics by default (of course, there are some minor snags with the interaction of rendering order and transparency, but nothings perfect).
- Slice through anything with the
CLIP_PLANESkeyword. - Make anything transparent with the
ALPHA_CHANNELkeyword. - Volume rendering.
- It’s easier to create a visualization for one destination (like a graphics window) and then send it to another (like the printer or a Postscript file).
- No system variables!
- With the iTools using object graphics, in most situations you can create a quick visualization as fast as in direct graphics (or should I say, in as much typing). (See some of the advantages of direct graphics below for a situation you can’t do this.)
- Since the
MAP_PROJ_*routines were introduced in IDL 5.6, it’s possible to do mapping in object graphics. - With IDL 6.2 and a decent graphics card, displaying images is faster in object graphics.
Of course, there are some reasons still to use direct graphics.
- While debugging a program, if you’re stopped at a line in the source code and want to make a quick visualization of one of the local variables, your options are limited. “Quick visualization” doesn’t really fit with hand coding object graphics, nor are the iTools an option in this situation since the event handlers for the widget program will not work. So I use direct graphics.
- There are still some tricks with pixmaps in widget programs that I think look better in direct graphics.
Feel free to comment below on your own findings about object graphics versus direct graphics. Does anyone have another great reason to use direct graphics (besides the learning curve)?
May 12th, 2006 at 1:52 pm
More than debugging, Direct Graphics is still the best way to use IDL in an ad hoc manner. Yes, I can display a line plot in iPlot, but it just takes too long to appear on the screen.
Note: I may be biased from years of using Direct Graphics.
May 16th, 2006 at 10:57 pm
As far as debugging Object Graphics, my favorite tool is XOBJVIEW. True, you don’t get the interactivity if you’re stopped at a breakpoint, but you can update your model tree from the command line then update the XOBJVIEW display via the REFRESH keyword. For example, (pretending we’re at a breakpoint in some executing code and our orb object is actually in the scope of the routine in which we have stopped)
IDL> orb = obj_new('orb', COLOR = [255, 0, 0])
IDL> xobjview, orb, TLB = tlb
IDL> xobjview, REFRESH = tlb ; since there's no expose event
IDL> orb->setpropery, COLOR = [0, 255, 0]
IDL> xobjview, REFRESH = tlb
Maybe there are some command line tricks for iTools, too?
May 17th, 2006 at 3:15 pm
With IDL 6.3, you can get around the breakpoint issue related to iTools by creating an IDL_IDLBridge and passing the display data to it. Since the bridge object is in a different process, its interpreter is free to get events from the tool. For example, compile and execute the following:
pro test
data = dist(32)
stop
end
If you attempt to execute
ISURFACE, dataat the command line, you’ll get the initial display, but none of the interactivity. However, if you send your data to a bridge object, you can have your cake and eat it, too.IDL> o = obj_new('idl_idlbridge')
IDL> o->setvar, 'data', data
IDL> o->execute, 'isurface, data'
You just have to keep in mind that your data are *copied* to the bridge so if you make any changes to the data in the scope of the routine in which you’ve stopped, you’ll need to copy those changes back over the bridge if you want to see them reflected there. You’ll also want to remember to destroy the bridge object before you exit the scope of the stopped routine otherwise you’ll leak heap.
As for debugging object graphics hierarchies at a breakpoint, you can always SAVE your model tree to a file, then in a bridge object, RESTORE the tree from file then debug it via a procedure, such as a call to XOBJVIEW.
May 17th, 2006 at 3:34 pm
That’s pretty cool. Although using the IDL_IDLBridge for this will not exactly be quick since the bridge has a non-trivial startup time plus the time to initialize the iTools system (they will have to initialized in the new session). For “quick visualizations” while debugging (as opposed to “serious analysis”), I think it would be slow.