> it's not just a network that can be slow. if you are concerned about
(Bperformance
(B> with your x apps, mere context switching is an issue. if you do it often
(Benough
(B> (and sit, blocking and waiting for a reply). this asynchronous behavior is
(B> highly desirable even for local communication. it allows x to take "system
(B> overhead" and minimise it severely - by design.
(B>
(B> though this is where the fun comes... not all xlib calls are asynchronous.
(Bsome
(B> are synchronous. they sit and WAIT for a reply from x. generally it is
(Badvised
(B> to AVOID these calls when you can or minimise their use. if you understand
(Bx at
(B> the protocol level you will know just which calls these are. some of them:
(B> XGetWindowAttributes, XSync, XQueryTree, XGetWindowProperty, XInternAtom,
(B> XGetImage.
(B
(BThis is TRUTH ... I had a "debate" one time with someone who claimed X was
(Basyncronous ... for the protocol, that is true, but using Xlib and with the
(Bcases stated, it is NOT. XGetWindowAttributes is probably the nastiest of
(Bthe bunch (I've seen apps do XGetWindowAttributes/XSetWindowAttributes
(Bhundreds of times during startup and/or worse opening a window). XInternAtom
(Band XGetWindowProperty are the other most common culprits.
(B
(BOne common app would XGetImage the area under the cursor so it could do a
(Bpretty "i beam" ... ugggggh
(B
(BRob
(B
(B_______________________________________________
(BDevel mailing list
([EMAIL PROTECTED]
(Bhttp://XFree86.Org/mailman/listinfo/devel
