[Xcb] GTK-XCB is in progress

[Barton C Massey]

Fine with me!  Please feel free to move or copy it there.

	Bart

In message <Pine.LNX.4.64.0611081630100.15762 at grozny.maths.univ-evry.fr> you wrote:
> Maybe that could go into the tutorial too (in the part # 18)
> 
> Vincent
> 
> On Wed, 8 Nov 2006, Jeremy Kolb wrote:
> 
> > Hi Bart,
> >
> > Can you put that on the wiki?  It would clear up some confusion...
> > especially when porting xlib programs to xcb.
> >
> > Jeremy
> >
> > Barton C Massey wrote:
> >> In message <934b4cdf0611072334j6c42d5b9i15f988e0834e3281 at mail.gmail.com>=
>  you wrote:
> >>> Oh, maybe I haven't made use of the round-trip delays sufficiently. I
> >>> understand that it is obvious to use round-trip when many requests are =
> sent
> >>> in a loop, so we can get the cookies together, then ask for all the rep=
> lies.
> >>> But in many situations that a single request is sent, we cannot suppres=
> s the
> >>> round-trips. Is that?
> >>
> >> The general ruleset I always intended for using a cookie to
> >> hide latency is this:
> >>   1. Always send a request as soon as you legally can.
> >>   2. Never force the returned cookie until you actually need
> >>      to examine the result.
> >> In the presence of multiple requests, it gets a bit more
> >> complicated.
> >>   1. Always send each request as soon as you legally can.
> >>      1a. If you can send multiple requests at the same time,
> >>          send the one whose value you expect to need first,
> >>          first.
> >>          1b. If rule 1a doesn't help, a secondary tiebreaker
> >>              is that it's better to send requests the server
> >>              can process quickly first, followed by those
> >>              the server might run slowly.
> >>   2. Never force a returned cookie until you actually need
> >>      to examine the result.
> >>
> >> The idea of rule 1b is that if you're lucky, you can be
> >> working on the quick results while the server is processing
> >> the slow request.  In general, don't worry about ordering of
> >> simultaneous requests too much.  It's hard to construct a
> >> realistic example where these kinds of corner cases matter.
> >>
> >> Note that rule 2 is stronger than necessary in the presence
> >> of multiple requests. If you need to force a cookie returned
> >> for a request r, it is harmless to also force cookies
> >> returned from requests earlier than r: these values will be
> >> available anyway, since the server always returns results in
> >> order.  However, it is also harmless to wait to force a
> >> cookie until you need the value, and it makes it clearer
> >> that you've done the right thing.
> >>
> >> If you follow these rules, you will be getting about all the
> >> latency hiding you can expect from what is a fundamentally
> >> serialized protocol without using threading or some
> >> equivalent mechanism.
> >>
> >> Hope this helps.  Comment welcome.
> >>
> >> =09Bart
> >> _______________________________________________
> >> Xcb mailing list
> >> Xcb at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/xcb
> >
>
> > --=20
> > Ce message a =E9t=E9 v=E9rifi=E9 par MailScanner
> > pour des virus ou des polluriels et rien de
> > suspect n'a =E9t=E9 trouv=E9.
> > Message d=E9livr=E9 par le serveur de messagerie de l'Universit=E9 d'Evry=
> =2E
> >
> >
> --8323328-2003000218-1162999845=:15762
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
> --8323328-2003000218-1162999845=:15762--