Open Bug 1283089 Opened 5 years ago Updated 3 years ago

Firefox 40+ are very sluggish through x2go


(Core :: Graphics, defect, P3)

47 Branch




(Reporter: danykey, Unassigned, NeedInfo)


(Keywords: regression, regressionwindow-wanted, Whiteboard: gfx-noted)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160515192858

Steps to reproduce:

Run Firefox 39 and Firefox 40 - 47 to compare.

I had test on Ubuntu 12.04 and Ubuntu 16.04 distros with similar results.

Actual results:

Firefox 39:
- top menu opens fast
- page scrolling is smooth

Firefox 40 - 47:
- top menu opens slow
- page scroll is renders very very slow with visual chunks

Expected results:

UI rendering performance should be fast as in Firefox 39.
OS: Unspecified → Linux
Component: Untriaged → General
What's x2go?

This should live in Untriaged so it gets triaged.
Component: General → Untriaged
Flags: needinfo?(danykey)
The x2go is famous open source application with client-server sides like VNC/RDP.
It's provides very fast remote desktop based on NX protocol.
Server part works with X server only. Client is exists for all popular OS.

Mainly it used in the corporate sector.

Official site:
Danykey, I can confirm the behavior you're reporting. There is a clear performance difference between FF38-39 and FF47 in X2go. Don't know if it's a piece of info we need but Chrome and FF47 are behaving almost the same(the scrolling chunky, top menu slow).

Therefore a regression range would be interesting to have for this bug. Danykey, if you'd like to help further you could try using mozregression and bisect to a set of changes that caused this. (
Ever confirmed: true
As I remember the Chrome was sluggish through x2go always.
So we use Firefox. If this issue woun't fixed it create a big problem to have fast browsing in the feature in X2go. Just now FF39 not so old but has security issues..sadly.
Thanks a lot for confirmation.
As per comment 3 adding the regression keyword. Although I'm not entirely sure that graphics is the right component, I think it's a step forward. Also, i'm adding it to my backlog to come back with a regression range.
Flags: needinfo?(adrian.florinescu)
Keywords: regression
Component: Untriaged → Graphics
Product: Firefox → Core
danykey, can you please install mozregression and try to investigate this locally? Seems like Adrian is not going to get to this anytime soon. It would also be worth noting if current versions are any better/worse.
Last good revision: 16bb246db6427c4131383beb1f71076ffedefc23
First bad revision: 8cd99e9b6034a6417ba17b426e6537ccb8aa9bf2


The above push log is from Nightly46, but I still can see a slight performance difference between Nightly41 and Nightly46, although not as significant as when comparing to the latest versions reported in this bug.

Although, this is definitely a step forward, the time frame doesn't actually fit and I think that the real cause of the regression is somewhere lower than the issue I managed to isolate.
Flags: needinfo?(adrian.florinescu)
Workaround: In about:config, set "gfx.xrender.enabled" to "true"

see bug 1180942 and bug 1280795
Flags: needinfo?(danykey)
Looks like a perf regression when using X11 remoting software.

I think this is fairly low priority. Ideally use Firefox locally, and use a proxy if you need the requests to go through a remote machine.

However, there may be a combo of prefs which help reduce the impact of this. jrmuizel?
Flags: needinfo?(jmuizelaar)
Whiteboard: gfx-noted
(In reply to Michael Kaufmann from comment #8)
> Workaround: In about:config, set "gfx.xrender.enabled" to "true"
> see bug 1180942 and bug 1280795

I confirm the workaround. Very helpful, thanks! Hopefully, in spite of what jrmuizel says on, this workaround will be supported in future versions, otherwise scrolling in Firefox is painfully slow over x2go remote desktop.
The same problem exists in recent versions of SeaMonkey.  The same workaround (setting gfx.xrender.enabled to true in about:config) works.
You need to log in before you can comment on or make changes to this bug.