Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!vsi1!daver!athsys!jim
From: jim@athsys.uucp (Jim Becker)
Newsgroups: comp.windows.x
Subject: Re: Detecting/Compressing Multiple Exposure Events - how ?
Message-ID: <130@tityus.UUCP>
Date: 1 Sep 88 21:36:01 GMT
References: <19880831130506.7.RWS@KILLINGTON.LCS.MIT.EDU>
Organization: Athena Systems, Inc., Sunnyvale, CA
Lines: 71

From article <19880831130506.7.RWS@KILLINGTON.LCS.MIT.EDU>, by RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler):
>     From: mit-vax!josh@bloom-beacon.mit.edu  (Joshua Marantz)
> 
>     Currently, I have to emulate that functionality with an XCheckIfEvent followed
>     by an XPutBackEvent, which has the annoying side effect of rearranging the
>     event queue.
> 
> As I pointed out in a previous posting, by using the arg value you can
> avoid having to pull anything out of the queue.  In general, Xlib
> functionality is rather unlikely to change if there are reasonable ways
> to build "convenience" routines on top of existing functionality.  That
> isn't to say that additional convenience routines aren't useful, just
> that they probably won't go into Xlib.  If people feel strongly that
> additional routines ought to be provided in some sort of utility library
> on the MIT release, we're willing to listen (and take code that comes
> with documentation).

	Here are my strong feelings, please listen !!

	There is a fairly simple modification that can be done to correct
this problem, which results in the additional functionality being added 
without increasing the already large number of Xlib calls. 

	The XCheck*() calls all take an XEvent pointer, which is used
to return the event to the application. In doing so, they take the
event out of the queue. A modification to this logic could check for a
NULL XEvent pointer being passed to the XCheck*() calls. This would
serve as a signal that the user does NOT want the event, merely to
know that one or more exist. Result being: The correct return status
would be returned and the queue would remain intact.

	The code modifications involved simply add an additional if{}
statement to the XCheck*() routines, which are pretty simple as stands.
The other alternative is to let users get at the queue itself, which I
consider to be potentially dangerous.

	Let me explain why this is such a big issue. In the current UI
paradigm that my company is using there can be hundreds of nested
windows within the layout of a single big window (which is the child
of the root).  When the single big window is mapped, deiconified or
otherwise exposed all these little guys get exposure events. If there
are multiple sets of exposes there is a lot of redundant processing.
(I believe that this is a common problem with some of the current
toolkits).  Our problem is additionally compounded by the graphics
editors having to access the database (with possible disk access) when
refreshing themselves.  Hence we have the need to contain the exposure
processing for better application throughput and responsiveness.

	The proposed solution of using XCheckIfEvent(), with continual
negative return status for each event in the queue, causes the entire
queue to be scanned for each curious query (each window!). It also
returns it's real status by "side effect", something I group with
"goto"s as far as cleanliness. If there are two hundred windows, with
a few sets of exposure events, you are doing a lot of work to look at
the entire queue for each window. Possibly, in this case, it is faster
not to try to compress the events!! (Our application currently STILL 
has over SIX hundred windows to contend with..uggh!).

	I believe that this would only cause minor mods in the five
XCheck*() routines, and the additional logic is trivial. I understand
that you guys have a lot to do to get R3 frozen, but this may be a
worthwhile change. If there are no other changes in these routines since
R2, I can make the changes and post them to xbugs. Ten minutes of fixes!

	One way or another, this will be a _very_ useful addition down
the road. Once people get more advanced in their use of X they will
want to "Check", as opposed to "Check & Get", the event queue.

	Enough leaning on on you busy guys -- thanks one way or the other!!


-Jim Becker