| Re: Mac Program Support [message #45249] |
Fri, 26 August 2005 07:31  |
K. Bowman
Messages: 330
Registered: May 2000
|
Senior Member |
|
|
In article <MPG.1d78d2c0bd4d4cd7989a5d@news.frii.com>,
David Fanning <davidf@dfanning.com> wrote:
> I am wondering if the problem is in creating draw widgets.
> Could this be slow because of the X11 connection? The other
> slowly appearing application that this woman told me about
> also uses quite a number of draw widgets.
Could be, but I couldn't begin to guess whether it is an IDL issue, a graphics
card driver issue, or some layer of Apple software in between.
It's also possible that it is something to do with POLYFILL. I seem to recall
that TVing a blocky image is much faster than drawing the equivalent with
POLYFILL.
Ken B.
|
|
|
|
|
|
|
|
| Re: Mac Program Support [message #45254 is a reply to message #45251] |
Fri, 26 August 2005 05:31  |
Haje Korth
Messages: 651
Registered: May 1997
|
Senior Member |
|
|
David,
so you are an IDL 1.0 user, too. I was still in high school when I had my
first experience with that version on the VAX. However, it seems that you
proceeded on the IDL learning curve a lot quicker than I did...
Anyway, with the introduction of the .full_session_reset in I believe 5.0
(?), I pretty much scrapped retall, because .f is just quicker to type than
retall, and most of the time it is also less keystrokes than getting
'retall' back from the command line buffer. So, why do I still need retall?
Cheers,
Haje
"David Fanning" <davidf@dfanning.com> wrote in message
news:MPG.1d781dcfcc165945989a5b@news.frii.com...
> JD Smith writes:
>
>> One of the joys of the active command line.
>
> I've been doing this a LONG time, but today I saw
> this on a PC, too. What in the world have I been
> paying attention to!? RETALL has *never* failed me,
> ever! I feel like I'm in some kind of time warp... :-(
>
> Here is another thing today that surprised me. Two people
> in the class have new Mac laptops. I have a little program,
> PickColorName, that displays 96 small draw widgets and fills
> them with a color with Polyfill. Colors appears instantaneously
> on a Windows PC. But on the Macs (both of them) the draw widgets
> appear all in black, then a second or so later the colors appear.
> It is VERY slow.
>
> I was shocked, really. I hear so much about how Macs are
> perfect for graphics applications, but this looked more like
> the VAX VMS workstations I learned IDL on 20 years ago.
> Any ideas about why this happens? One of the Mac users
> told me it is common with some of her applications, too.
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Mac Program Support [message #45255 is a reply to message #45254] |
Fri, 26 August 2005 04:37 |
George N. White III
Messages: 56
Registered: September 2000
|
Member |
|
|
On Thu, 25 Aug 2005, David Fanning wrote:
> Here is another thing today that surprised me. Two people
> in the class have new Mac laptops. I have a little program,
> PickColorName, that displays 96 small draw widgets and fills
> them with a color with Polyfill. Colors appears instantaneously
> on a Windows PC. But on the Macs (both of them) the draw widgets
> appear all in black, then a second or so later the colors appear.
> It is VERY slow.
>
> I was shocked, really. I hear so much about how Macs are
> perfect for graphics applications, but this looked more like
> the VAX VMS workstations I learned IDL on 20 years ago.
> Any ideas about why this happens? One of the Mac users
> told me it is common with some of her applications, too.
If those were PC's you would look for VISTA (VIruses, Trojans,
Spy-ware, and Add-ware) stealing cycles.
Are the Macs connected to a network?
A couple weeks ago my WinXP system became sluggish and started giving
"Windows delayed write failed" errors. The initial diagnosis, after
ruling out VISTA or a bad disk, was a bad network adapter, but after
replacing the mainboard twice, and trying different ports on the ethernet
switch, I swapped the system for another PC and got the same symptoms.
It turned out the network interface (set to autonegotiate) was running
100/half while the switch was coming up 100/full. Now that I know what to
look for, I found the another PC on the same switch with the same problem.
Linux on the same PC's was also sluggish (copying files by ftp maxed out
at 40kB/s).
People pay a lot of attention to user interface experiences, but hardly
any attention to diagnostics to determine why a system seems sluggish. In
my experience (heavily weighted to unix and PC's), hardware failures,
network infrastructure issues, VISTA, and disks at 99.6% of their capacity
are all common reasons for users asking for new machines (e.g.,
substandard performance with their existing machine).
--
George N. White III <aa056@chebucto.ns.ca>
|
|
|
|
|
|
| Re: Mac Program Support [message #45259 is a reply to message #45256] |
Thu, 25 August 2005 18:27 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
JD Smith writes:
> One of the joys of the active command line.
I've been doing this a LONG time, but today I saw
this on a PC, too. What in the world have I been
paying attention to!? RETALL has *never* failed me,
ever! I feel like I'm in some kind of time warp... :-(
Here is another thing today that surprised me. Two people
in the class have new Mac laptops. I have a little program,
PickColorName, that displays 96 small draw widgets and fills
them with a color with Polyfill. Colors appears instantaneously
on a Windows PC. But on the Macs (both of them) the draw widgets
appear all in black, then a second or so later the colors appear.
It is VERY slow.
I was shocked, really. I hear so much about how Macs are
perfect for graphics applications, but this looked more like
the VAX VMS workstations I learned IDL on 20 years ago.
Any ideas about why this happens? One of the Mac users
told me it is common with some of her applications, too.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Mac Program Support [message #45261 is a reply to message #45259] |
Thu, 25 August 2005 14:28 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Wed, 24 Aug 2005 20:37:27 -0600, David Fanning wrote:
> JD Smith writes:
>
>> Not a Mac-only issue, but if you have a big backlog of the same events
>> which triggered the crash, all queued up in the event system (e.g. a bug
>> in your motion event handling, just as you've scribbled all around a
>> draw widget), then RETALL will simply allow the next event to come
>> through, and trigger the bug again, putting you right back where you
>> started (or so it would appear). Once you fix the bug and re-compile
>> the program, the events flow through freely. But, sometimes you just
>> want to get the heck out and do something else though. I use the
>> following snippet (actually bound to a key in IDLWAVE) to first clear
>> all events from the queue, and then RETALL:
>
> This sounds like the scenario, although I've never seen it before. I can
> understand if you process another queued event with a RETURN, but with a
> RETALL!? Seems weird to me.
One of the joys of the active command line.
JD
|
|
|
|
| Re: Mac Program Support [message #45265 is a reply to message #45261] |
Wed, 24 August 2005 19:37 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
JD Smith writes:
> Not a Mac-only issue, but if you have a big backlog of the same events
> which triggered the crash, all queued up in the event system (e.g. a
> bug in your motion event handling, just as you've scribbled all around
> a draw widget), then RETALL will simply allow the next event to come
> through, and trigger the bug again, putting you right back where you
> started (or so it would appear). Once you fix the bug and re-compile
> the program, the events flow through freely. But, sometimes you just
> want to get the heck out and do something else though. I use the
> following snippet (actually bound to a key in IDLWAVE) to first clear
> all events from the queue, and then RETALL:
This sounds like the scenario, although I've never seen it
before. I can understand if you process another queued event
with a RETURN, but with a RETALL!? Seems weird to me.
Also, running my (award winning!) FSC_SURFACE program produces
a boat load of underflow warnings. What is that about? And why,
RSI, can't we turn these damn things off easily?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Mac Program Support [message #45267 is a reply to message #45265] |
Wed, 24 August 2005 14:09 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Wed, 24 Aug 2005 12:52:37 -0600, David Fanning wrote:
> Folks,
>
> Since this has turned into a Mac support help-line, I have a question.
> Person in my IDL class today has a new Mac running IDL 6.2. She crashed in
> a widget event handler and couldn't get out.
>
> I said "Type RETALL". She did, and she *still* couldn't get out of the
> event handler code. We had to recompile the program itself before we could
> get back to the main IDL level. Is this normal? Did I miss something? I
> didn't have time to stop and ponder this, but it was weird.
Not a Mac-only issue, but if you have a big backlog of the same events
which triggered the crash, all queued up in the event system (e.g. a
bug in your motion event handling, just as you've scribbled all around
a draw widget), then RETALL will simply allow the next event to come
through, and trigger the bug again, putting you right back where you
started (or so it would appear). Once you fix the bug and re-compile
the program, the events flow through freely. But, sometimes you just
want to get the heck out and do something else though. I use the
following snippet (actually bound to a key in IDLWAVE) to first clear
all events from the queue, and then RETALL:
__wa=widget_info(/managed)
for i=0,n_elements(__wa)-1 do widget_control,__wa[i], /clear_events
retall
JD
|
|
|
|
| Re: Mac Program Support [message #45345 is a reply to message #45259] |
Fri, 26 August 2005 10:13 |
Henry
Messages: 8
Registered: April 2005
|
Junior Member |
|
|
There are a couple different ways people launch X11 on the Mac and they
can have dramatically different graphic display speeds.
I don't recall all the details. (In part I don't fully understand the
layering of the different X11/Aqua/OSX/etc components, and in part my
experience was during a recovery from a system corruption 36 hours
before a major deadline.) If I installed plain old X11 from Apple
(with 10.4 it's on the install disk) and launch the X11 application,
IDL graphics are fast. If installed other versions and used them (e.g.
OroboroOSX) then IDL graphics were extraordinarily slow. (even on my
2xG5 2.5Ghz)).
My guess is the answer is to full reinstall X11 and use Apple's
version, rather than one of the installs.
cheers,
-henry
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
