Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse) Newsgroups: comp.windows.x Subject: Re: graphicsexpose handling Message-ID: <9106221632.AA00670@lightning.McRCIM.McGill.EDU> Date: 22 Jun 91 16:32:10 GMT Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 36 >> 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