Joseph Pingenot <[EMAIL PROTECTED]> writes:
> Hello.
>
> I'm somewhat new to in-depth X-ness, but I've been following a usenet
> thread, and the following post came up:
> [I apologize if my in-depth-newbieness shows through; please be patient :]
>
> "I wish X11 were good enough I could resolve 2 real world problems my company
> is having with it's use.
>
> 1) Some older custom written (contractor) X11 apps served from a Big Endian
> OS that pukes when Xinput can't provide a Big Endian response back from an
> X86 Linux boxen. There is no source code, and the contractor is no longer
> in business. The app has no commercial equivalent.
It's sounds like one of two things:
- A buggy XInput implementation in the "Big Endian OS's" libXi
- A buggy XInput implementation in the XFree86 server
It's more likely to be the first; though I wouldn't deny the
possibility of the second. The X protocol hides virtually all
endianess issues from clients.
(You do mean XInput? graphics tablets?)
There is nothing that can done about this other than fix the bugs.
> 2) With a fixed 60ms delay between remote sites, a Remote X11 Client/Server
> application takes almost a second per mouse (xinput) selection for a
> database app just for a menu response to manifest itself at the display.
> The same app locally is instantaneous. The problem is bi-directional
> because X11 is non-asynchronous multiple transactions with it's X11
> client/server handshaking (font, colors, geometry, xinput, menu population,
> etc.). At 60ms per handshake, it adds up to unacceptable application delay.
> The solution seems to be only to access a remote Windows 2000 Terminal
> Server (using ICA/RDP) that has a local proximity X11 server to the X11
> application host, and deal with a single compressed stream of ICA display
> data across the WAN."
This basically means a badly written toolkit or application. With
a properly written toolkit, it's very seldom that the toolkit
needs to retrieve data from the server.
(You say that "X11 is non-asynchronous" but actually the X protocol
is about as asynchronous as you can get, and Xlib exposes a
good deal of that asynchronicity to applications and toolkits.
That doesn't mean that toolkits can't do stupid things.)
General rule:
- Round trips bad ... latency is the killer
- Pushing lots of data through the connection doesn't matter much
Putting the toolkit on the server side might well make things worse
because the application *does* need to get information from the
toolkit quite frequently.
(That being said, I'm a little skeptical of ever having good interactive
GUI performance over a WAN ... once latency gets up beyond 20-30ms
a Java-applet style architecture is most likely going to be the
best way to have things be snappy.)
Regards,
Owen
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
