Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!well!jef
From: jef@well.sf.ca.us (Jef Poskanzer)
Newsgroups: comp.windows.x
Subject: Re: graphicsexpose handling
Message-ID: <25556@well.sf.ca.us>
Date: 20 Jun 91 18:56:45 GMT
References: <25529@well.sf.ca.us>
Reply-To: Jef Poskanzer <jef@well.sf.ca.us>
Organization: Acme Software
Lines: 19

In the referenced message, jef@well.sf.ca.us (Jef Poskanzer) wrote:
}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.

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.

I still wonder if there's a cleaner solution.
---
Jef

  Jef Poskanzer  jef@well.sf.ca.us  {apple, ucbvax, hplabs}!well!jef
                     WCBG: All Elvis, All The Time