Re: nsterm.m: How to prevent _inactive_ window update from overreaching.

[Alan Third <alan@idiocy.org>]

On Sun, Nov 25, 2018 at 06:14:19PM -0800, Keith David Bershatsky wrote:
> I isolated the issue to the following changes within nsterm.m that
> were made between the dates of 07/07/2018 and 11/16/2018. The
> additions (+) permit crosshairs to work properly; whereas, the
> subtractions (-) cause the issue outlined at the beginning of this
> thread.
> 
> The crosshairs code (in the attached patch from 11/16/2018) work
> correctly on all three GUI platforms: NS, NT, X11.
> 
> Is it possible that something in the changes below is responsible
> for the issue, rather than the crosshairs code itself?

Well, yes, in that your patch simply undoes the key changes required
for macOS Mojave compatibility.

However the crosshair code needs to behave itself WRT the expose
functions. I strongly suspect it isn’t.

I’m not sure how either really works, so I can’t point out what needs
done without some investigation. It’s possible we just need to call
the crosshair code from somewhere similar to the various places we
call the cursor code in nsterm.m.

Because we can’t draw directly to the screen any more, when redisplay
is running all we can do is mark the parts of the frame that need
updated. Later we call expose_frame on those parts and it does the
actual drawing.

That process must be working to some extent. I don’t know your code
very well but I suspect the crosshair code is called when the cursor
is redrawn. If part of the frame is marked as dirty, but that doesn’t
include the cursor, then the cursor isn’t redrawn and therefore your
crosshair code will not be called. Does that make sense?

If that is the case we need to work out how to ensure the crosshair
code is called even if the cursor is not redrawn.

I’ve had a quick look at the patches and, if I’m honest, it would take
me some time to work out what’s going on. How is the crosshair drawn?
-- 
Alan Third