cls@leibniz.uucp (Carol Sullivan) (03/24/89)
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.
Our window event notification requirements are obviously more
stringent than the usual static window user's. However, we are
hopeful that there is some simple means for us to obtain the
required extra information that does not seriously compromise our
"hands off" approach to the Mac O.S.
Any ideas concerning how we may obtain the needed information
would be greatly appreciated.
Thanks,
Ray McNamara
(613) 763-8670
Dept 1P21
Bell-Northern Researchtrebor@biar.UUCP (Robert J Woodhead) (03/25/89)
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 *
tecot@Apple.COM (Ed Tecot) (03/30/89)
In article <404@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes: >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. I wouldn't recommend this. Regions are relocatable blocks and are in an indeterminate state at interrupt time (they could be in the process of being relocated). Several real-time video cards work by reserving a special color table entry. Any portion of the screen which has that "color" is instead drawn with the video input. _emt