🚀 go-pugleaf

In writing scrollbars for a minimal toolkit I have come across a little
puzzler.  The usual event sequence for a scroll is: the user clicks,
the window's contents get scrolled, a graphicsexpose gets generated for
the newly visible portion, and the gexpose gets handled.  Now let's say
the user clicks a scroll, and then while the resulting gexpose is being
handled the user clicks again.  Now the event sequence is click,
gexpose, click, gexpose.

But what happens if the user clicks three times in rapid succession?
It goes click, gexpose, click, click, gexpose, gexpose - and the second
gexpose is handled *incorrectly*, since the third click has already
modified the window's scrolling position.

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 also tried avoiding gexposes by doing the necessary repaints directly
while handling the click event.  This works perfectly until you have
another window partially overlapping the scrolling window.  Then the
server generates gexposes anyway.  Not much I can do about that.

Does anyone know what I'm talking about?  I looked inside Xt and it's
doing something weird with expose events, but I'm not sure whether it's
to solve this problem or just an optimization or something else.
---
Jef

  Jef Poskanzer  jef@well.sf.ca.us  {apple, ucbvax, hplabs}!well!jef
           "...and now for something completely different."