RE: Slow application launch in Outlook with xwinclip.exe running

["Harold Hunt" <huntharo at msu dot edu>]

Eric,

Interesting.  I've heard reports of this before.

However, I'm unable to duplicate this problem.

I suspect that the problem has something to do with the fact that X events
don't come in that often, so we may not process our Windows events in a
timely manner.  I have been searching forever for a non-blocking equivalent
to XNextEvent... and I finally found one!  Here is Owen Taylor's response to
someone looking for the same thing:
http://www.xfree86.org/pipermail/xpert/2001-December/013978.html

===========================================================================
> For reasons to do with a user interface element I'm working on,
> I need something like select.  Do the XCheck*Event() functions
> block?  I'm really reluctant to use pthreads, as this isn't portable
> enough for what I'm trying to do.
>
> Specifically, if the app is in a certain state, I want to update the
> window every 1/32 of a second, but I need to keep processing events too.
> If XCheckWindowEvent() doesn't block, and is reasonably quick, it will
> do perfectly.  Does it?

The standard way of doing a non-blocking check is

 if (XPending (display))
   {
     XNextEvent (display, &event);
   }

Using any of the XCheck*Event functions can be relatively slow, since
they need to search the entire queue. (If you had to use one, I'd
suggest using XCheckIfEvent with an appropriate predicate. But XPending()
should be as good or better.)

Of course, what real toolkits do is select() on ConnectionNumber(display)
to know when they need to call XPending() without having to poll
continuously.
===========================================================================


I was very intrigued to see this.  This not only means that I can make
xwinclip better, but it means that I can finally integrate clipboard support
into XWin.exe, since we'll actually be able to see some sort of shutdown
message, rather than having XNextEvent fail and call exit ().  (Obviously
you can't integrate a clipboard client in the server if every time you reset
you call exit ()... cause you would exit instead of resetting.)

I've done a small rewrite of xwinclip to use select () on both the X event
handle and /dev/windows (which is a socket that watches the Windows message
queue).  This should solve the problem that you are seeing with Outlook
because we will process our Windows messages in a timely manner.

I'll post the new xwinclip in just a few minutes.

It won't be long now until we can get rid of xwinclip and have clipboard
integration directly in XWin.exe.

Harold