🚀 go-pugleaf

>> I thought at first I could solve this by doing an XCheckMaskEvent
>> before my XNextEvent and always handling any queued expose events
>> before any other kind.  And this does indeed work correctly in the
>> debugger.  But in realtime there is a race and it has the same bug
>> as before, the second gexpose gets handled after the third click.

mterm has this same race when scrolling.  The README file says

- There's a race which will occasionally cause a damaged area of the
  window to not be repainted.  The race occurs when an exposure of some
  sort happens and mterm scrolls at about the same time, such that the
  server sees the CopyArea for the scroll after the exposure, but mterm
  doesn't see the exposure event until after the scroll.  This should
  be fixable, but it looks like a good deal of work, and it doesn't
  happen very often.

(It actually happens to me often enough to be very annoying.)

> I ended up solving the problem by doing this plus having the
> clickproc do an XSync after the XCopyArea.  This forces the
> just-generated gexpose into the input queue, where it can be handled
> right away.  And it only slows things down if the user does a whole
> bunch of scrolls, which doesn't happen too often.

Are you sure this fixes it?  Even with XSync(), you still have to be
very careful to offset events correctly.  (Using XSync narrows the
window but still doesn't close it.)

> I still wonder if there's a cleaner solution.

I don't think so.  Someday I'll get around to fixing mterm....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu