This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.
Julian Bradfield writes:
On 2018-10-30, Sam <sam@email-scan.com> wrote:
Scanning through https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html I can't seem to find anything that seems to require the server to always send responses to requests in the order they were received, and process requests in the order they were received.
Interesting point. I agree with you - and I can't see any reason why
it should be required, apart from the difficulty of working out when
one can do this.
Whether client libraries/programs are written to cope with it is
another matter.
If it's not required, then some kind of a round-trip ping is needed. The NoOperation request is a one-way trip only, and is not sufficient.
Currently, I am abusing the InternAtom request for this, to know when the server processed all requests that preceded it. This is how I arrived at
this conundrum.
I am intentionally using a sub-optimal environment, where the client and the server are across a network that includes a wireless AP. This is to make suboptimal drawing algorithms be more visible.
I can process MotionNotify events as fast as they come in, generating a pile
of X and RENDER requests as a result. But with a couple of hops across the network, it's surprising how many X and RENDER requests can fill up in the intermediate network buffers, before the server goes through them; which (especially RENDER composition) create a lot of work for the server. My
display was noticably lagging behind the pointer, as much as 2-3 seconds,
even though my client was doing nothing, waiting to receive the next event.
I fixed this by sending an InternAtom just before flushing out all my work,
and then waiting for the response to the InternAtom, which arrives only
after the server dealt with my preceding requests. Once the InternAtom
response was received, with anything that came before it getting held in
/my/ queue, the existing logic that I already had in place dealt with all
the queued up MotionNotify events, only processing the last one. No more apparent visual lag.
This trick will only work as long as the server processes all requests serially. If someone gets the bright idea to optimize responses out of sequence, where possible, this will defeat this workaround. The server seems
to already be capable of throwing me MotionNotify events while it's chewing away at the request backlog.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJb2PR+AAoJEGs6Yr4nnb8lWuUQAMImV+uxYGWF3dFUn3zbKbBC cQuDYCp2vxB8h4rx4dqB8CMWq+Ok7ZQP5Q8Ihvlx4qyRqkRz1xGZ2jQDr8uME22U vBOB+c15OECRQz0CWVkqJFJnyoYagWbnEoRXu6BdiW1EcYJG2xP7GPFj+pQp3dI0 j/fZL1ZKiwdZFlJaA8oKJ+GbbmXl/0q/BoLVRn/HRJS/tmfmle7Fj1fIuMUhVcBx JbHTOIuDSuNEP9XMzatuJhAT4VE5RVlyl9lfJKdlwzdVqfjZdSdqlx5pfpa532Ds o2USaKgGSSkG+ge66HpaJtrQPBHuIeL2fhKURh2npPGAJOD8b4BWsipGQM04gwxw C+96ZKYxmbRYVQzkJX/HxstwgAhmPis1zRdnKHw6GTKI0QfJvJYNjbl1dKiSS365 8LhoyX8HcYamIy2bYxoWrn3GY7StIhJ7AbdYtMzLr4z4F4b6ZStZSD2jZdMhMjX1 Axgl1PuzSnUgDbUnyaoYkHZkN0BpM8J0nM1TEG8dFIgOWlSNvbPe8a06cPkBYjyw Jns7bwDGaHI5bvjZOa+ASLV3zWKFc3BJHdwmcXIDcM+rmYe1iLBpQbanmZ07xpRr DPzelxKE0EGFph9xGo0fjIDPd2xeHkYZuouO5TBUNMLI9UmQFG4ltsGEeOzxS/Hz bcyLXSYPmTG30Wln2cBJ
=80Bp
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)