Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!biar!trebor
From: trebor@biar.UUCP (Robert J Woodhead)
Newsgroups: comp.sys.mac
Subject: Re: video windows on the mac
Message-ID: <404@biar.UUCP>
Date: 25 Mar 89 06:13:44 GMT
References: <369@bnr-fos.UUCP>
Reply-To: trebor@biar.UUCP (Robert J Woodhead)
Organization: Biar Games, Inc.
Lines: 41

In article <369@bnr-fos.UUCP> cls@leibniz.uucp (Carol Sullivan) writes:
>We are developing a 24 bit hardware card that streams video to 
>conventional Mac windows. Clearly the H/W will have to be 
>reprogrammed whenever the on screen window geometry changes so 
>as to cause occlusion or exposure of our H/W painted VisRgn, or for 
>that matter, the video window is dragged, resized etc. 
>
>Any ideas concerning how we may obtain the needed information 
>would be greatly appreciated.

Off the top of my head, I can think of two approaches:

You only need to reprogram your hardware when one of two things happen;
either 1) your window moves or 2) a window movement or activation causes
a change in your visRgn.  Therefore, so long as you can be assured that
no application is painting directly to the screen without paying any
lip service to the window manager, all you should have to do is patch
the window manager traps so that you get notified when a window moves
or the front/back ordering changes.

Alternatively, for a quick and dirty implementation, you might be able
to get away with checking for a change in your window's portRect and
visRgn during the vertical blank interval.  The portRect check is
trivial, and you might be able to get away with a check for the visRgn
as follows : if the handle hasn't changed (ie: curVisRgnHdl^=oldVisRgnHdl^)
AND the handle is the same size, then it's very likely that the visRgn
hasn't changed.  The real question here is "When the window manager
changes a visRgn, does it generate the new region (in a new handle),
set the visRgn to point to the new region, and free up the old visRgn?"
If it does, then on any window manager call that changes your window's
visRgn, the handle is going to change, which you can easily detect.
In this situation, the only possibility for a failure is if, between
two vertical blank intervals, two window manager calls are executed
that result in a different region _of_the_same_size_ being allocated
in the most recently freed area of the heap, so that the visRgn handle
_appears_ to change.

-- 
* Robert J Woodhead * The true meaning of life is cunningly encrypted and *
* uunet!biar!trebor * hidden somewhere in this signature...               *
* Biar Games, Inc.  *                       ...no, go back and look again *