On Fri, 17 Dec 2004 17:31:35 -0800 "Robert Currey" <[EMAIL PROTECTED]> babbled:
(B
(B> > the protocol level you will know just which calls these are. some of them:
(B> > XGetWindowAttributes, XSync, XQueryTree, XGetWindowProperty, XInternAtom,
(B> > XGetImage.
(B>
(B> This is TRUTH ... I had a "debate" one time with someone who claimed X was
(B> asyncronous ... for the protocol, that is true, but using Xlib and with the
(B> cases stated, it is NOT. XGetWindowAttributes is probably the nastiest of
(B> the bunch (I've seen apps do XGetWindowAttributes/XSetWindowAttributes
(B> hundreds of times during startup and/or worse opening a window). XInternAtom
(B> and XGetWindowProperty are the other most common culprits.
(B
(Boh yeah. hell yeah. actually - writing wm's has made me acutely aware of all of
(Bthis. i am going to the extent of trying to remove get property requests
(Bentirely right now by first listing (a round trip unfortunately) then only
(Bfetching the properties that exist (at that time) that i care about (as a wm),
(Bthen relying on property change events to fetch any that get added later. but
(Beven this sucks. this is where xcb rules the roost. it talks raw x protocol. i
(Bcan just send off my property fetch requests (and atom fetches at the start) all
(Bnicely batched off and get them back later as asynchronous reply "events". since
(Bthe hole codebase is entirely event driven this works perfectly within the
(Bexisting coding model. BUt the issue here is programmers knowing all this and
(Bspending the time to optimise through it are rare - most think in "get/reply"
(Bscenarios where when the function returns the information has been fetched and
(Bhanded back to the app. it takes a bit of mind bending to start thinking of your
(Bentire app as being asynchronous - even to your display. xlib was written with i
(Bguess the assumption that such mental gymnastics are often beyond a lot of
(Bprogrammers and thus xlib hides it. i do say it is easier to do it that way too
(B- until you realise the ugliness of the overhead behind it all and recoil in
(Bshock. :)
(B
(B> One common app would XGetImage the area under the cursor so it could do a
(B> pretty "i beam" ... ugggggh
(B
(Bas long as it queued the get for "idle time" (ie just before it goes back to a
(Bselect() or a blocking wait for events etc.) making sure it didn't do it for
(Bevery single mouse motion event... this won't be THAT bad... well not on a local
(Bmachine (network badness will vary on nastiness of the network) :) a few round
(Btrips per event cycle isn't too bad as new events are buffered/batched and then
(Bdealt with in a batch so the app is a bit jerkier but it "plays catch-up" to the
(Binput stream. unfortunately a lot of software does not do this. they do work for
(Bevery mouse motion or whatever event. if the expense of dealing with those
(Bevents is greater than the time between events... the app is in grave trouble.
(Bthe problem here is... run the app on a slow/old machine and this scenario is
(BMUCH more likely... now the app falls increasingly behind "realtime" (where the
(Buser has their mouse now or what events have happened) and this is when evilness
(Breally shows its head and you notice how poorly programmed that client is.
(B
(B> Rob
(B>
(B> _______________________________________________
(B> Devel mailing list
(B> [EMAIL PROTECTED]
(B> http://XFree86.Org/mailman/listinfo/devel
(B>
(B
(B
(B--
(B------------- Codito, ergo sum - "I code, therefore I am" --------------
(BThe Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
$BMg9%B?(B [EMAIL PROTECTED]
(BTokyo, Japan ($BEl5~(B $BF|K\(B)
(B_______________________________________________
(BDevel mailing list
([EMAIL PROTECTED]
(Bhttp://XFree86.Org/mailman/listinfo/devel
