| Re: Help! Slow object graphics. [message #29460 is a reply to message #29458] |
Tue, 19 February 2002 18:42   |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ted Cary (tedcary@yahoo.com) writes:
> Partly as a learning exercise, and partly based on advice from the
> newsgroup, I went ahead and wrote a 2D object graphics program based on
> XROI.
Uh, oh. As one who provided advice (although I can't recall
suggesting you modify XROI!), I feel obligated to respond.
Alternatively, and probably more appropriately, I could
pretend my newsgroup server just lost this article. :-)
> The graphics tree branches out from the XROI graphics tree, which
> is to say the graphics hierarchy in my program shares its basic
> structure with XROI. The drawing functions are essentially borrowed
> from XROI as well.
I'm trying to imagine what this means. It sounds ominous,
but I guess you just mean whatever graphics model you
created is drawing into the viewport established by the
XROI program. That is certainly OK.
> The problem is that drawing in my program is ridiculously slow, much
> slower than in XROI. During freehand drawing the pixels activated on
> screen lag noticeably behind the cursor position. Simple animations
> where I erase and redraw sequences of filled ~20-vertex polygons are
> also very slow, and take three times as long as in an earlier direct
> graphics version of the same program.
Something obviously sounds wrong here. Unfortunately, if you take
the number of ways you can write bad direct graphics code (say 185,965)
and multiply it by 100, you come up with approximately the number of
ways you can screw up object graphics code. It is just extremely
hard to say what is going wrong without having a peak at the code.
And even then it is often pretty much a crapshoot. I know there are
some solutions I've coded up five different ways before settling
on something that "seemed" to work OK.
> The big difference is that my program is written as an object widget,
> since I envisioned subclassing it into several specialized ROI analysis
> programs. So everything might be buried a little deeper in the heap
> (pointers to pointers), although I notice that the info structure of
> XROI is in a pointer as well... Anyway, can this really account for
> the marked reduction in speed?
No. There is pretty much nothing faster than pointers to pointers.
This can't be the problem.
> If not, then I can't figure it out,
Well, in all sincerity, one week is not NEARLY enough time. :-)
> The computer I'm using is not great, but is fairly new--733MHz Mac
> G4, 32Mb NVidia GeForce 2Mx, 256Mb + 895Mb(Virtual) RAM.
Sounds good enough to me. Have you tried this using
the software renderer, by the way? The hardware renderer?
Any difference there?
> I convinced my employer that converting my DG program to OG was worth
> the week it's taken, but I'm not sure he'll be so pleased to see that
> everything is slower than it was before...
Well, bring up the subject of printing and this will look
like pretty small potatoes, I'm sure.
> I thought object graphics
> weren't supposed to be so slow these days, so it must be the way I'm
> programming, although I really just copied XROI for the drawing part of
> the program.
I personally think you have a programming problem, but (as I say)
I can't offer any specific suggestions. You get a feel for these
things eventually. I guess my most useful advise would be to
keep trying. Don't be afraid to change things.
I'd have a look at object instancing as a way to speed some of
the animation things up. (Thanks to Mark Hadfield, I have a new
version of my ZOOMBOX program up that does this correctly now.
It only took me a year to figure THAT out!)
Good luck with this, and keep us informed.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
