| Re: Help! Slow object graphics. [message #29445] |
Wed, 20 February 2002 11:51 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ted Cary (tedcary@yahoo.com) writes:
> I wouldn't be plotting any data at all in object graphics. I'd use the
> object graphics XROI-type program to *acquire* the data from ROIs drawn in
> an image, and then I'd plot the analyses of the data in direct graphics
> windows--maybe in something downloaded from your website. My question was
> only if I could *use* both object graphics and direct graphics in the same
> IDL session without any problems--not in the same window, not drawing the
> same visuals. I have used them both simultaneously before, drawing DG plots
> from the command line while OG programs are running, etc, but I do not know
> if there could be unforeseen problems in the long run while running a
> program. I am trying to get the best of both worlds without the worlds
> colliding.
As long as you are on a 24-bit display and you
are reasonably careful about colors (you may have
to load your color table before you draw graphics
in some circumstances, etc.), there is no problem
running both direct graphics and object graphics
windows simultaneously. I do it almost transparently
all the time.
> It seems like OG might be good for "graphics" graphics--3d spinning coins
> and christmas trees with flashing lights and hopefully ROI-drawing
> utilities--but maybe it is still not so convenient to plot data with it?
Well, I'm pretty sure I didn't say *that*. I think
I said I am finding more and more reasons to use
object graphics, since often the advantages of doing
so outweighs the drawbacks. But you do have to carefully
weigh your options for each project. There are some things
that simply can't be done *without* object graphics. In
those cases, I'm always thrilled to have them. :-)
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
|
|
|
|
| Re: Help! Slow object graphics. [message #29447 is a reply to message #29445] |
Wed, 20 February 2002 10:31  |
Ted Cary
Messages: 53
Registered: October 2001
|
Member |
|
|
>
> No, object graphics and direct graphics are two completely
> separate things and can't be combined in any way, shape, or
> form. You can certainly *use* both in the same IDL session,
> obviously. But you can't draw direct graphics into an object
> graphics window, or visa versa. Perhaps you could "plot" your
> data in a direct graphics window, but why would you want to do
> that after you had gone to the trouble of doing it in object
> graphics?
I wouldn't be plotting any data at all in object graphics. I'd use the
object graphics XROI-type program to *acquire* the data from ROIs drawn in
an image, and then I'd plot the analyses of the data in direct graphics
windows--maybe in something downloaded from your website. My question was
only if I could *use* both object graphics and direct graphics in the same
IDL session without any problems--not in the same window, not drawing the
same visuals. I have used them both simultaneously before, drawing DG plots
from the command line while OG programs are running, etc, but I do not know
if there could be unforeseen problems in the long run while running a
program. I am trying to get the best of both worlds without the worlds
colliding.
It seems like OG might be good for "graphics" graphics--3d spinning coins
and christmas trees with flashing lights and hopefully ROI-drawing
utilities--but maybe it is still not so convenient to plot data with it?
|
|
|
|
| Re: Help! Slow object graphics. [message #29451 is a reply to message #29447] |
Wed, 20 February 2002 09:21 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ted Cary (tedcary@yahoo.com) writes:
> I should clarify that this program is not a modification of XROI. I just
> use XROI as a starting point since I know it can draw ROIs fast enough on my
> machine, and since this is my first object graphics attempt. So what's
> borrowed from XROI is the graphics tree and the drawing functions. I'm not
> drawing to the View established by XROI or anything like that, it's just
> that I set up my graphics tree up the same way. at least the lower branches.
> Another difference is that my draw windows handle larger pictures than XROI
> by using scroll bars-certainly this is not the problem.?
I shouldn't think so.
> Do object graphics still have those postscript printing problems?
We don't like to think of these as "problems". We prefer
the term "features". Things have obviously improved a bit,
especially for "simple" graphics output (I.e., those without
any color filling or textures) which can be "vectorized".
Everything else still takes a month and a day to get through
your printer. Which wouldn't be so bad if the whole world
didn't have to stop when you did it. Let's just say well-timed
coffee breaks help.
> If this
> has not been fixed, can't I just plot my data to direct graphics windows and
> print those?
No.
> It is possible to combine direct graphics and object graphics
> in the same session, at least, if not in the same window. as long as colors
> are protected, right?
No, object graphics and direct graphics are two completely
separate things and can't be combined in any way, shape, or
form. You can certainly *use* both in the same IDL session,
obviously. But you can't draw direct graphics into an object
graphics window, or visa versa. Perhaps you could "plot" your
data in a direct graphics window, but why would you want to do
that after you had gone to the trouble of doing it in object
graphics? Then you have to write everything in *both* systems.
Even for someone like me, that seems excessive.
> I've never used Insight but was playing around with the Live_ things. They
> are a little slow and not very intuitive to use in a program, but they seem
> like they might be useful as wrappers for plot objects. Is the aversion to
> them just based on programmers' healthy hatred of anything point-and-click,
> or are there bigger problems?
I think the healthy hatred stems from them not working
the way you want them to and wanting to change them, only
to find there is no code to do so. Then the healthy
paranoia kicks in and you wonder what RSI is hiding
in that code they won't show you. :-)
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
|
|
|
|
| Re: Help! Slow object graphics. [message #29452 is a reply to message #29451] |
Wed, 20 February 2002 07:56 |
Ted Cary
Messages: 53
Registered: October 2001
|
Member |
|
|
> 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. :-)
I should clarify that this program is not a modification of XROI. I just
use XROI as a starting point since I know it can draw ROIs fast enough on my
machine, and since this is my first object graphics attempt. So what's
borrowed from XROI is the graphics tree and the drawing functions. I'm not
drawing to the View established by XROI or anything like that, it's just
that I set up my graphics tree up the same way. at least the lower branches.
Another difference is that my draw windows handle larger pictures than XROI
by using scroll bars-certainly this is not the problem.?
Don't worry, David, as I recall your advice to me was to use direct graphics
objects, which was what I was doing in a previous version of the program. I
got tired of writing my own DG objects that just mimicked the functionality
of the built-in IDLgr objects, and actually the object graphics version of
the code has fewer lines than the DG version because I don't have to define
so many new things. Also, I just wanted to learn object graphics.
Do object graphics still have those postscript printing problems? I saw
that on the old newsgroup postings and was hoping that was something that
had been fixed by now, especially considering the number of complaints, and
considering how many object graphics converts seem to be around. If this
has not been fixed, can't I just plot my data to direct graphics windows and
print those? It is possible to combine direct graphics and object graphics
in the same session, at least, if not in the same window. as long as colors
are protected, right? Or is there some other problem with this?
I've never used Insight but was playing around with the Live_ things. They
are a little slow and not very intuitive to use in a program, but they seem
like they might be useful as wrappers for plot objects. Is the aversion to
them just based on programmers' healthy hatred of anything point-and-click,
or are there bigger problems?
Thanks
|
|
|
|
| Re: Help! Slow object graphics. [message #29458 is a reply to message #29452] |
Tue, 19 February 2002 20:59 |
Pavel A. Romashkin
Messages: 531
Registered: November 2000
|
Senior Member |
|
|
On an inferior machine (G4 400) I run OG code fast enough not to have to use
DG code almost ever (well, except for the pitiful lack of usefulness in
IDLgrContour).
I am a little scared of basing my projects on something like RSI's X*
series. They remind me of LIVE* series and that infamous Insight thing. I
feel if I make it all from scratch I at least know what part can be slow.
I am sure you can find the culprit in your code. Or better yet, try
downloading an existing OG program and see how would it work for you. Google
search on OG visualsisation should turn up a few choices.
Good luck,
Pavel
> Snip...
> 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... 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 hope it's not the heap thing, because I depend on the
> object widget functionality... Any ideas? Thanks.
>
>
>
|
|
|
|
| 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
|
|
|
|
| Re: Help! Slow object graphics. [message #29461 is a reply to message #29460] |
Tue, 19 February 2002 17:13 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
I would first try using the idl profiler procedure (see help). You'll need
to figure out where your program is wasting its time. I wish I could tell
you more. Although I have run into the "man my program is slow" problem
before, I don't have any quick fix answers for you.
Once you narrow your problem down post your findings.
-Rick
"tedcary" <tedcary@yahoo.com> wrote in message
news:3C72DFDE.E3E10AA@yahoo.com...
> 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. 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.
>
> 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.
>
> 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? If not, then I can't figure it out,
> since as far as I can tell my program is using almost exactly the same
> draw functions and graphics hierarchy as the faster XROI. There are no
> PRINT or HELP statements slowing things down by writing to the output
> log. The computer I'm using is not great, but is fairly new--733MHz Mac
> G4, 32Mb NVidia GeForce 2Mx, 256Mb + 895Mb(Virtual) RAM.
>
> 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... 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 hope it's not the heap thing, because I depend on the
> object widget functionality... Any ideas? Thanks.
>
>
>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
