From: scott@mcl.ucsb.edu (Scott Bronson)
Newsgroups: comp.sys.mac.programmer
Subject: Stymied++!  VBL Cursor Watching ideas?
Keywords: VBL Cursor
Date: 21 Jul 92 06:34:45 GMT

(The postincrement represents the minor cookie at the end of this letter.)

I've run into a real snag with my cursor-watching VBL idea (that I posted
to the 'net a few days ago--it may be archived if the article has expired).
Basically, I cannot see a good way to make my code future-compatible without
taking an incredible performance hit.  Here are the ways that I have tried:

The first way I tried was the fastest.  I was getting upwards of 170 iterations
per tick by PPosting() an event, checking the event's modifiers field that got
filled in, then flushing it.  A lot of people frowned on this idea, so I tried
a few other techniques.  Unfortunately, none performed better.

OSEventAvail and EventAvail are out.  I cannot get more than 48 iterations per
tick using OSEventAvail, and EventAvail ended up somewhere around eight iters
per tick.  Totally unacceptable if they are to be VBLs because they'd probably
suck up more cycles than save.

GetKeys runs in great time.  I can get 127 iterations per tick using some
cool key-watching code that I came up with.  Then I decided that I shouldn't
just *assume* that GetKeys can be called from a VBL.  I was astounded that it
can't!  Such a fast, low-level call that may move or purge memory?!?  Rats.

So, I'm stuck.  Here are my options as I see them now:

o Use my super-fast first idea of posting and always flushing the event, hoping
  that because the event is always flushed and because the event gets posted
  and removed by a VBL, the system will not be able to choke on it.
o Use some slow code based on OSEventAvail that I have up and running, but can
  only get 48 iterations per tick (on a IIci).
o Patch some other trap (GNE?) so that I can use my sufficiently fast GetKeys
  code.  Problem is, your traps get disabled when your app gets switched out.
o Use some other solution that I haven't thought of yet (and you're going to
  tell me :-).

I'd like to hear what you guys think would be best.  Right now I think I'll
keep using the first code that I posted, but waking up my application with
WakeUpProcess() rather than leaving the app1 event in the queue.  Am I
overlooking something obvious?  Is it possible and future compatible to
install a patch that will not be removed when my app switches out?

Pipe Dream: Obviously PPostEvent can get at the current state of the
modifiers super-quick and at VBL time.  Is it possible for me to do the
same?

Just doing my part to save precious machine cycles...

	- Scott


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I thought it would be a real shame that my tuned key-watching code would
go unused, so I'm hoping that someone else may find it useful.  If you do
use it, all I ask is that you mail me a short letter telling me how.  I will
support this code if you have any questions.  This code is now public domain.

	short gOldKeys = 0L; // Global var holding current state of modifiers

	Boolean ModifiersChanged( void )
	{
		KeyMap km;
		register Boolean on = false;
		asm {
			PEA	km
			GetKeys
			MOVE.L	km[1],D1
			ANDI.W	#0x800F,D1
			CMP.W	gOldKeys,D1
			BEQ.S	@exit
			MOVE.W	D1,gOldKeys
			MOVEQ	#1,on
		@exit:
		} return on;
	}
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.misc