It's very possible that Meterbridge's "waste" isn't in the X calls, but the way in which it collects information and/or performs I/O in general. Years ago when I first started to dabble in open source code and came upon a fairly popular IRC client called "BitchX". The author of that client decided in his infinite wisdom to basically cpu-spin on non-blocking I/Os for "petty" network transfers, thereby wasting about 85+% CPU to oversee a single client-to-client transfer that was probably running at 2-4 kilobytes/second, tops. It was insanely bad code. Many people writing software against UNIX APIs often don't understand them and the frameworks which went into their design. If you can, try to profile where Meterbridge is wasting all of its time. "Overupdating" the screen is another classic problem of "naive" implementations. Doing more than 60 updates/second is really wasted as the monitor isn't going to really display (much) more than that. Yes, the "overhead" of maintaining update-to-update throttles is insignificant compared to blasting thousands of bits faster than can be displayed. In my humble opinion, the human eye isn't going to really notice faster than 20-30 updates/second, and I don't think more than that is at all useful. An exception perhaps is if you use "inertial" object motion whereby you maintain precise Xvelocity and Yvelocity, updating it at the maximum refresh rate is a win for smoothness as the inter-frame object displacement can be smaller which is much more pleasing. =MB= -- A focus on Quality.

On Sat, Jul 31, 2004 at 03:11:41PM +0100, Steve Harris wrote: SDL itself works fine remotely AFAICT. What doesn't work remotely is DGA or GLX hardware rendering. Some programs require shared memory too which obviously won't work remotely. And obviously, you won't get any sound ;) -- Ryan Underwood, <nemesis(a)icequake.net>

Malcolm Baldridge wrote: The X server is what you have on your machine. It handles display requests from client applications (possibly run remotely). At least, that's my limited understanding of how it's meant to work. Cheers, Chris

OK, my apologies for needlessly confusing the mess. Not all crypto algorithms are the same cost. Blowfish is perhaps the lightest-weight crypto method, with 3DES, IDEA, and CAST (pure-C/shared-lib version) being the most expensive. Careful selection of the crypto method can make a big difference. Also, try explicitly disabling compression. That may induce too much latency delays in screen updates. The reverse may also be true, i.e., things may improve if you have mild (compressionlevel =3 or 4) compression enabled. Also, some of the crypto cores in OpenSSL only have non-PIC assembler implementations, so you'll get 30-50% faster crypto speeds on CAST for example if you build both OpenSSL and OpenSSH statically. Just as a cpu cost comparison (Pentium 4, gcc-3.3, OpenSSL 0.9.7d-static): rc5 (may not be available to SSH) rc4 (may not be available to SSH) blowfish/aes-128 (neck-and-neck, though bf is a wee bit faster) cast (this falls to 3DES if using the shared-lib version) 3DES IDEA NOTE! To get the asm CAST core built into your OpenSSL library, you have to pass no-shared to the configure option when building it. What I do is configure it with shared, build, test, and install OpenSSL, and then "make clean", re-configure WITHOUT static, build it, and then manually install libssl.a and libcrypto.a into my /usr/lib It seems that OpenSSL builds even the "static" library with PIC when you configure OpenSSL to build "with shared libs" as a time-saving measure - this causes the build system to pick the Pure C version only. One other point: most SSL-using services on Linux are NOT threaded, so you might gain a few % points by building non-threaded SSL libraries. I don't think this is probably worth that much, but for the bleeding edgers, multi-threaded code DOES come with some performance penalties if you're not using it in a threaded application. Good luck, =MB= -- A focus on Quality.

On Sun, 2004-08-01 at 00:39, Robert Jonsson wrote: Is XDMCP running over ssh? I'm using it on MDK 10 to port the display to my WInblows XP laptop thru X-Win32. Works great. It was having a problem with Keepalive timeouts and the session dying. I think the machine was going into suspend. I changed the settings in the BIOS and it has been fine since. I leave VNC running as a backup in case the other dies! I use the thing at gigs this way...although still working out minor bugs, it is reliable and robust. R~