arie@eecs.umich.edu (Arie Covrigaru) (03/26/91)
When I have MacDraw II open and go to use a terminal emaulator, I see that MacDraw II is doing something in the background because the echo on my terminal emulator is very jittery. I know why FileMaker has this much activity but I can't understand why a drawing program would do in the background. So my question to Claris is: What is happening, why and how can this be stopped. -- ============================================================================= Arie Covrigaru | University of Michigan AI Lab Phone: (313)763-1255 | Room 149, Advanced Technology Bldg. Internet: arie@eecs.umich.edu | 1101 Beal Ave., Ann Arbor, MI 48109 =============================================================================
baumgart@esquire.dpw.com (Steve Baumgarten) (03/26/91)
In article <ARIE.91Mar25110031@dip.eecs.umich.edu> arie@eecs.umich.edu (Arie Covrigaru) writes:
When I have MacDraw II open and go to use a terminal emaulator, I see
that MacDraw II is doing something in the background because the echo
on my terminal emulator is very jittery. I know why FileMaker has this
much activity but I can't understand why a drawing program would do in
the background.
So my question to Claris is: What is happening, why and how can this be
stopped.
I wouldn't mind finding out either, since it seems to cause problems
even when MacDraw II is in the foreground. That is, there are times
when it takes 1 or 2 seconds for anything to happen when I click in a
drawing window. Then, when I let go of the mouse button, the cursor
remains the "pointing hand" cursor for about a half-second or so
before changing back into the arrow cursor. Very annoying.
This happens under System 6.0.7 on a IIci, Finder and Multifinder, no
INITs running. I believe we're running version 1.1 of MacDraw II.
--
Steve Baumgarten | "New York... when civilization falls apart,
Davis Polk & Wardwell | remember, we were way ahead of you."
baumgart@esquire.dpw.com |
cmcl2!esquire!baumgart | - David Lettermantime@ice.com (Tim Endres) (03/27/91)
In article <BAUMGART.91Mar25133837@info7.esquire.dpw.com>, baumgart@esquire.dpw.com (Steve Baumgarten) writes: > So my question to Claris is: What is happening, why and how can this be > stopped. > > I wouldn't mind finding out either, since it seems to cause problems > even when MacDraw II is in the foreground. That is, there are times > when it takes 1 or 2 seconds for anything to happen when I click in a > drawing window. Then, when I let go of the mouse button, the cursor > remains the "pointing hand" cursor for about a half-second or so > before changing back into the arrow cursor. Very annoying. I wonder if they are not doing some type of "garbage collection"? Boy, wouldn't that be something :) Heap? We don't need no stinkin' Heap... :) ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
baumgart@esquire.dpw.com (Steve Baumgarten) (03/27/91)
In article <1CE00001.bfaigj7@tbomb.ice.com> time@ice.com (Tim Endres) writes:
I wonder if they are not doing some type of "garbage collection"?
Boy, wouldn't that be something :) Heap? We don't need no stinkin'
Heap... :)
Could be, but it seems like it goes on all the time. Once it starts,
that's it.
I'm going to have to experiment more to see exactly what combination
of System Software and hardware set it off. I don't think it happens
on our Mac II running System 6.0.5, but it sure happens a lot on our
IIci running 6.0.7.
--
Steve Baumgarten | "New York... when civilization falls apart,
Davis Polk & Wardwell | remember, we were way ahead of you."
baumgart@esquire.dpw.com |
cmcl2!esquire!baumgart | - David Lettermannick@cs.edinburgh.ac.uk (Nick Rothwell) (03/28/91)
In article <1CE00001.bfaigj7@tbomb.ice.com>, time@ice.com (Tim Endres) writes: > I wonder if they are not doing some type of "garbage collection"? > Boy, wouldn't that be something :) You sound surprised. If, for "garbage collection", you instead say "purging of resources" then it sounds quite likely, although the Mac Toolbox is probably doing it, not MDII. MS Word was doing the same on this Mac Plus here. I wondered what it was, then when I checked the free heap space, it said "15K". "Ooohh," thought I. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ "I see what you see: Nurse Bibs on a rubber horse."
rick@claris.com (Rick Boarman) (03/31/91)
There's a couple possibilities:
1) Low memory. We don't do any special garbage collection or weird
heap management. The ToolBox slows down pretty bad when free memory is
less than about 100k.
2) Large files. If there more than about ten thousand objects things can
get a bit slow (unless you have an fx).
3) Inits. This is our biggest source of problems. Many inits eat up a lot
of time and memory. Of all the calls to tech support a huge number turn
out to be either a strange or multiple system folders related problems.
The program itself does very little during idle time. It just tracks the
cursor and does some upkeep tasks. What are we doing about this? Well,
in MacDraw Pro we have switched over to new system calls that better
support MultiFinder (MacDraw II is a fairly old program as far as code
goes). We've done a lot to optimize performance and help manage memory
better. For instance, MacDraw II keeps an offscreen buffer the same
size and bit depth as the monitor. We now crop the buffer as the window
size shrinks and we don't let it grow too big.
Hope this helps.
Rick
--
* Rick Boarman * UUCP: {ames,apple,portal,sun,voder}!claris!rick
* Claris Corp. * Internet: rick@claris.com
* * AppleLink: Boarman
Opinions are mine alone and do not reflect Claris policy.arie@eecs.umich.edu (Arie Covrigaru) (03/31/91)
>>>>> On 30 Mar 91 21:38:35 GMT, rick@claris.com (Rick Boarman) said: | There's a couple possibilities: | 1) Low memory. We don't do any special garbage collection or weird | heap management. The ToolBox slows down pretty bad when free memory is | less than about 100k. | 2) Large files. If there more than about ten thousand objects things can | get a bit slow (unless you have an fx). | 3) Inits. This is our biggest source of problems. Many inits eat up a lot | of time and memory. Of all the calls to tech support a huge number turn | out to be either a strange or multiple system folders related problems. | The program itself does very little during idle time. It just tracks the | cursor and does some upkeep tasks. What are we doing about this? Well, | in MacDraw Pro we have switched over to new system calls that better | support MultiFinder (MacDraw II is a fairly old program as far as code | goes). We've done a lot to optimize performance and help manage memory | better. For instance, MacDraw II keeps an offscreen buffer the same | size and bit depth as the monitor. We now crop the buffer as the window | size shrinks and we don't let it grow too big. | Hope this helps. | Rick | -- | * Rick Boarman * UUCP: {ames,apple,portal,sun,voder}!claris!rick | * Claris Corp. * Internet: rick@claris.com | * * AppleLink: Boarman | Opinions are mine alone and do not reflect Claris policy. Actually, I still don't understand. In my original posting I asked what is MacDraw II doing in the background when I am using ANOTHER program (for example a terminal emulator). Your explanation seems to answer the question (if it would have been asked) what is MacDraw II doing in the background when I am using it, not when it is in the background. -- ============================================================================= Arie Covrigaru | University of Michigan AI Lab Phone: (313)763-1255 | Room 149, Advanced Technology Bldg. Internet: arie@eecs.umich.edu | 1101 Beal Ave., Ann Arbor, MI 48109 =============================================================================
baumgart@esquire.dpw.com (Steve Baumgarten) (04/03/91)
In article <251@claris.com> rick@claris.com (Rick Boarman) writes:
The program itself does very little during idle time. It just
tracks the cursor and does some upkeep tasks.
What are we doing about this? Well, in MacDraw Pro we have switched
over to new system calls that better support MultiFinder (MacDraw
II is a fairly old program as far as code goes). We've done a lot
to optimize performance and help manage memory better. For
instance, MacDraw II keeps an offscreen buffer the same size and
bit depth as the monitor. We now crop the buffer as the window
size shrinks and we don't let it grow too big.
These sound like great improvements, and I'm looking forward to
MacDraw Pro. But there have been several times when MacDraw II 1.1 on
a IIci running 6.0.7 (no INITs; running either Finder or Multifinder)
just seems to take forever to respond to user events of any kind.
Clicking causes the pointer to change to the hand cursor -- which then
stays that way for a second or two before changing back into the
pointer. It's fabulously annoying when it happens....
Anyway, we'll be getting Pro when it's released, and I suspect that
will be the end of our problems. Thanks for the info.
--
Steve Baumgarten | "New York... when civilization falls apart,
Davis Polk & Wardwell | remember, we were way ahead of you."
baumgart@esquire.dpw.com |
cmcl2!esquire!baumgart | - David Letterman