t-stephp@microsoft.UUCP (Stephen Poole) (04/18/89)
I'm working on an LSC program that is very calculation intensive. My event loop checks for the usual events and after processing any makes a call to my calculation routine. This routine takes a small fraction of a second (typically about .1 - .2, I'd guess), during which time it calculates the path of a particle and whether or not it is going to result in anything visual. If so then I plot a short line or a single point. The problem is that my mouse cursor flickers horribly. Up until the point where I open a new window and begin these calculations it is perfectly steady, but this calculation routine is causing it to go nuts. It seems to me that the problem is just because I'm not calling WaitNextEvent frequently enough, but it will take some serious rewriting to check for events between every calculation instead of between groups of calculations. Am I correctly assessing the problem? Is there some general guideline about how frequently GetNextEvent must be called? Thanks for any help. -- -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- -- -- -- I'm just an Oregon Tech Software Engineering co-op at Micro- -- -- soft. Believe me, nobody here pays attention to my opinions! --
sho@pur-phy (Sho Kuwamoto) (04/18/89)
In article <5522@microsoft.UUCP>t-stephp@microsoft.UUCP (Stephen Poole) writes:
<I'm working on an LSC program that is very calculation intensive. My
<event loop checks for the usual events and after processing any makes
<a call to my calculation routine. This routine takes a small fraction
<of a second (typically about .1 - .2, I'd guess)[...]
<The problem is that my mouse cursor flickers horribly. [...]
<It seems to me that the problem is just because I'm not calling
<WaitNextEvent frequently enough, but it will take some serious
<rewriting to check for events between every calculation instead of
<between groups of calculations.
<Am I correctly assessing the problem? Is there some general guideline
<about how frequently GetNextEvent must be called? Thanks for any help.
I doubt this is the problem. The mouse is redrawn at interrupt time,
not on a Get/Wait NextEvent. I may be missing the obvious, but unless
you install some ruthless VBL tasks, there should be no reason for
the mouse cursor to flicker. I'd check for a more serious error
if I were you. Sometimes bugs on the mac create completely arbitrary
symptoms.
-Shoksitze@nmsu.edu (Kevin Sitze) (04/20/89)
<I'm working on an LSC program that is very calculation intensive. My
<event loop checks for the usual events and after processing any makes
<a call to my calculation routine. This routine takes a small fraction
<of a second (typically about .1 - .2, I'd guess)[...]
<The problem is that my mouse cursor flickers horribly. [...]
<It seems to me that the problem is just because I'm not calling
<WaitNextEvent frequently enough, but it will take some serious
<rewriting to check for events between every calculation instead of
<between groups of calculations.
<Am I correctly assessing the problem? Is there some general guideline
<about how frequently GetNextEvent must be called? Thanks for any help.
You might check your drawing, if you do a large amount of drawing to
the screen then (if the mouse is over the area being drawn to) you'll
see the cursor 'flicker' as it's being erased and redrawn.
If you just are doing calculations and virtually no drawing, VBL tasks
may be the culprit. GetNextEvent never affects the cursor updating
(assuming a DA isn't asking for time). WaitNextEvent may or may not
affect the mouse (I would say not) if you are passing a non-nil mouse
region to it. (I personally can't see any reason for WaitNextEvent to
be changing the cursor sense it only needs to check the mouse location
but who knows, I've seen Apple do stranger things...)
--
----------------------------------------------------------------------
_______________ |
| ___________ | | From the Macintosh of:
| | o o | | | Kevin Sitze
| | > | | | Wk. Phone #: 646-6206
| | \___/ | | |
| |___________| | | Internet E-Mail Address:
| | | ksitze%nmsu.edu
| | |
| Mac ----- | | Physical Mail Location:
|_______________| | Kevin Sitze
| = | | 601 S. Melendres
|_____________| | Las Cruces, NM 88005
|
More fun than... | (Just call me Kelesi)
----------------------------------------------------------------------lsr@Apple.COM (Larry Rosenstein) (04/21/89)
In article <2735@carthage.cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > I think it's more likely that the bits _beneath_ the cursor are being > redrawn. If this happens, they overwrite the image of the cursor, and > then the VBL has to put the cursor back on top of them: flicker. The You are right about the cause of the flicker (I think), but your explanation is backwards. The way things happens is that Quickdraw calls the routine ShieldCursor which hides the cursor if it intersects given rectangle. It then calls ShowCursor when the drawing is finished. I've also encountered one case in which Quickdraw calls ShieldCursor unnecessarily. If you do a CopyBits on a Mac Plus (I never tried other machines, but think this was fixed), the cursor will be shielded even if the copy is entriely offscreen. When I wrote my paint demo in MacApp, I couldn't figure out why the cursor would be hidden for certain operations, and this turned out to be the problem. (It was especially noticeable because the CopyBits operation took 1.5 seconds and the cursor was hidden the whole time.) Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1