I figured as much... more or less what I'm ending up with is the
equivalent of running 'xvnc4viewer localhost' forwarded to my windows
machine.
Not really, though; that's actually how i've been handling persistent X
apps until getting xpra to successfully build this morning, and i never
noticed this kind of lag. Forwarded VNC would be ideal in my case,
except that I'm being forced to use the xorg-video-dummy driver, which
limits me to a 640x480 root (it's a headless system only because it's an
all-in-one with a fried GPU; no chance at getting real graphics drivers
running on it at all).
I was hoping that I'd have at least comparable performance using xpra,
as it allows me to run apps fullscreen and still have the 'security' of
knowing that, if my connection drops, my application is still running. I
currently have to choose between the two, which is certainly less than
ideal.
I'm very close to running ubuntu in a VM so I can do everything in a
more native environment; RAM is a consideration on this laptop so i'm
trying to avoid that; i've got plenty to spare on the server, so I
prefer to use it for any 'heavy lifting'. Add to that... this is only
one of several linux systems on which I plan to deploy my eventual
solution...
xpra is the ideal solution if I can figure out a way around this issue
also, i did check again and my network connection is NOT nearly idle
when the lag occurs; however, my laptop's 802.11g (actual data rate was
54mbit at the time) is at most 33% utilized, while the server (on
100mbit ethernet) was otherwise not utilizing it's network adapter. It's
definitely not a network capacity issue.
Nathaniel Smith wrote:
On Thu, May 28, 2009 at 2:52 PM, Keith Bronstrup <[email protected]>
wrote:
Just to clarify, both the copies of xpra (daemon and client) are
running on
the same machine, with the client being forwarded via PuTTY (SSH) to an
instance of Xming.
This isn't a configuration that I really took into account when
designing xpra, so I'm not surprised if it doesn't work well... you
may end up combining the worst aspects of both X and xpra's respective
protocols. (Drawing over X can be efficient because you can send
commands like "draw a line" and "copy region A to region B" (very
useful for scrolling), while xpra doesn't have that kind of high-level
semantic knowledge about what the app is doing so it just sends big
blocks of pixels for everything. OTOH, X's protocol tends to be much
more sensitive to high-latency links.)
That said, I don't know why it would be *that* bad; the way the xpra
client uses X shouldn't be making *that* many round trips, and a quick
skim of the source doesn't reveal any obvious problems (unless maybe
you're resizing your window a bunch, but I assume not). To debug
further, I'd probably want to examine -d protocol and xtrace logs for
the client, but I'm not sure how much of a priority I'll be able to
make this.
(There are also some patches on the list for running the xpra client
under windows directly, though IIRC they don't have support for ssh
yet. When windows support gets finished then you'll also have that
option.)
-- Nathaniel
_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
