Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!ora!bloom-beacon!dont-send-mail-to-path-lines
From: pete@iris49.biosym.COM (Pete Ware)
Newsgroups: comp.windows.x
Subject: graphicsexpose handling
Message-ID: <9106201944.AA21772@iris49.biosym.com>
Date: 20 Jun 91 19:44:12 GMT
References: <25529@well.sf.ca.us>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 27

To deal with it correctly, you need to keep track of all you scrolling
actions until a gexpose (or noexpose) event arrives to indicate it is
finished.  chuck@fid.Morgan.com (Chuck Ocheret) recently posted
something called "Panhandler" to the motif mailling list that deals
with this problem.  To quote from his description:

    This problem is the result of the asynchronous nature of X.  If you
    have an occluding window over the rectangle you are trying to pan, the
    your XCopyArea() calls can result in GraphicsExpose events since some
    areas couldn't get copied.  However, you might not see those
    GraphicsExpose events until after you have done a bunch of pans.

    When the GraphicsExpose events eventually get to your client, you have
    already scrolled the damaged areas to new locations, so that the x, y
    members of the GraphicsExpose events need to be adjusted.

    This is what the PanHandler fixes for you.  It maintains a queue of
    your pan requests and keeps it up to date with respect to incoming
    Expose, GraphicsExpose and NoExpose events.  It adjusts the Expose and
    GraphicsExpose events accordingly so that you repair the right
    portions of your window.

I haven't actually used the code so you on your own.

--pete
Pete Ware / Biosym / San Diego CA / (619) 546-5532
     email: pete@biosym.com