🚀 go-pugleaf

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