[clug] Virtual desktop infrastructure (VDI) for Linux Desktops

steve jenkin sjenkin at canb.auug.org.au
Tue May 9 03:49:54 UTC 2017


> On 7 May 2017, at 15:55, David C via linux <linux at lists.samba.org> wrote:
> 
> Steve, in principle, you're right. Firefox over X11 is terrible, so plan B is called for.
> 
> On 7 May 2017 3:37 pm, "steve jenkin via linux" <linux at lists.samba.org>
> wrote:
> 
>> Have I missed something?
>> Wasn’t X-11 invented to solve this precise problem?
>> 
>> [the ‘client’ and ‘server’ model, where the ‘X-11 server’ is the display
>> device.]

David,

Have you tried a 'lightweight’ browser over the same config / network / systems?
That’d identify where things are going and lead you towards an optimum solution, not a kludge.

If Firefox is the problem, looking to a faster-over-remote browser is a more scalable & maintainable solution than a remote desktop.
Or the problem might be the mismatch in X-11 / OpenGL / GPU driver configs between the client and X-11 server.
Or simply that ‘xrender’ support was removed.

A reddit user reported a significant performance hit going from Firefox 46 to Firefox 47.
Regressing versions to one with xrender support might give you a quick work-around and suggest a fastpath to a permanent solution.

> FF 47 unbearable slow over remote X11
> <https://www.reddit.com/r/firefox/comments/4nfmvp/ff_47_unbearable_slow_over_remote_x11/>
> We use XDMCP or x2go to connect to a server (via Gigabit Ethernet) and where scrolling was super smooth on FF46, FF47 is laggy as hell,
> just like Chrome always was.
>  It seems that it doesn't use native X11 rendering anymore
>  but renders the whole webpage as one graphic, 
> which then needs to be retransmitted completely to the client.
>  I couldn't find anything in the changelog regarding this.
>> This is because we disabled XRender support.

The (performance) fault you’re talking about was logged in 2005.
It was never fixed.

From the comments, what you’re seeing is a very well known problem with ‘chatty’ protocols like MSFT's RPC's:
	“It works fine locally, but performance crashes over the network”.

> Performance of Firefox over X11 remote display, and equivalently under VNC, is unbelievably/unusably slow
> <https://bugzilla.mozilla.org/show_bug.cgi?id=299727>
>> I tried using xmsgtrace to see what X protocol messages were being sent, but there were several thousand, more than I can easily examine with the knowledge of Firefox that I have.

This piece suggests there’s an ‘xrender’ setting that you can set in Firefox that might improve your performance over the network.
Is this pre v.47? didn’t check.
One comment mentions ‘webgl’ - I didn’t follow that lead.

> Firefox’s graphics performance on X11
> <http://www.hackermusings.com/2012/05/firefoxs-graphics-performance-on-x11/>
>> go to about:config and set “gfx.xrender.enabled” to “false”.

Here are two threads to read, with explicit suggestions of things to try.
[web-proxy + local F’fox, VPN, SSH forwarding, FreeNX, tweak X-11 settings, lower screen resolution/colours]

how to make fast SSH X11 forwarding (specifically, making firefox context menu show up quickly)
<https://serverfault.com/questions/63871/how-to-make-fast-ssh-x11-forwarding-specifically-making-firefox-context-menu-s>
> Remote Firefox over SSH is pretty usable until you try a right click to make context menu show up. It takes about 5 seconds for the context menu to appear. It seems it takes many round trips.
> 
> ssh -c blowfish-cbc -C -Y host

and

> Give FreeNX a try.
[Now ‘nomachine’, <https://www.nomachine.com> ]

Fastest browser to run over a forwarded X11 session
<https://superuser.com/questions/403594/fastest-browser-to-run-over-a-forwarded-x11-session>
> There are a few browsers that run a bit (to much) better over X11 forwarding.
> Midori is a lightweight, tabbed browser that should run well.
> Xlinks2 should work over X11 forwarding pretty well as well.
> uzbl and surf are both browsers I've used that should work well over X11 because they're very minimal.

> Even if you use a browser that is light-weight on CPU and RAM on the server, in this case the limiting factor will undeniably [1] be the network. What you want to avoid is mostly unnecessary screen rendering.
> 	• Turn off "smooth scrolling" and such features. Use PgUp/PgDn instead of continuously scrolling if you have the choice (a single screen update is much faster than 30 just to see a full page).
> 	• Keep a small browsing window (but not so small so you have to scroll a lot more as per previous point).
> 	• Block animated material (animated GIFs are not that common nowadays, so blocking flash will probably do fine).
> 	• Consider using VNC, which will compress the image transfer in a clever way. This gives me a much snappier experience when forced to use GUI over slow connections.
> 	• Don't underestimate text-based browsers if there is something you quickly need to do on the server.
> 	• Proxy and/or port tunneling through SSH avoid/s the problem completely. You just want to transfer the information, it is unnecessary to transfer the complete presentation layer.
> 
> [1]: Unless you have a very fast connection (~100Mbps in my experience); then any browser will probably do without being more annoying than using the browser locally. I am blessed with this in my remote needs.
> 
>> This answer is actually much better than the chosen answer.
>> The complexity of the browser has nothing to do with how fast it runs over X11 forwarding, 
>> only how often it needs to send screen update information, 
>> which depends on configuration and usage. 
>> Additionally, you can lower the resolution or number of colors which will dramatically increase responsiveness.
>>  Having said this, uzbl is a good choice because it uses key bindings natively although most browsers can be configured in the same way using plugins. This will help reduce lag further. 

HTH
steve

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin




More information about the linux mailing list