[Parti-discuss] local xpra sessions laggy as heck

[Keith Bronstrup]

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 <keith at bronstrup.com> 
> 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
> Parti-discuss at partiwm.org
> http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
>