1283089 - Firefox 40+ are very sluggish through x2go

Status: NEW

(Core :: Graphics, defect, P3)

Description

[danykey]

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.

Comment 1

[:Gijs (he/him)]

What's x2go?

This should live in Untriaged so it gets triaged.

Comment 2

[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: www.x2go.org

Comment 3

[Adrian Florinescu [:aflorinescu]]

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. (http://mozilla.github.io/mozregression/)

Comment 4

[danykey]

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.

Comment 5

[Adrian Florinescu [:aflorinescu]]

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.

Comment 6

[u279076]

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.

Comment 7

[Adrian Florinescu [:aflorinescu]]

Last good revision: 16bb246db6427c4131383beb1f71076ffedefc23
First bad revision: 8cd99e9b6034a6417ba17b426e6537ccb8aa9bf2

Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=16bb246db6427c4131383beb1f71076ffedefc23&tochange=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.

Comment 8

[Michael Kaufmann]

Workaround: In about:config, set "gfx.xrender.enabled" to "true"

see bug 1180942 and bug 1280795

Comment 9

[Kelsey Gilbert [:jgilbert]]

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?

Comment 10

[odulon]

(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 https://www.reddit.com/r/firefox/comments/4nfmvp/ff_47_unbearable_slow_over_remote_x11/, this workaround will be supported in future versions, otherwise scrolling in Firefox is painfully slow over x2go remote desktop.

Comment 11

[Tristan Miller]

The same problem exists in recent versions of SeaMonkey.  The same workaround (setting gfx.xrender.enabled to true in about:config) works.

Comment 12

[Michael Kaufmann]

Unfortunately, the setting "gfx.xrender.enabled" has been removed in Firefox 93, see bug 1724936.

Comment 13

[Tristan Miller]

It still exists in SeaMonkey 2.53.11.1, and will probably continue to exist for quite some time, though eventually SeaMonkey will catch up with Firefox. Is there a different workaround that can be used in Firefox?

Comment 14

[:Gijs (he/him)]

If this still happens on Firefox, a performance profile from the Firefox profiler would probably be helpful.

Comment 15

[davestux]

(In reply to :Gijs (he/him) from comment #14)

If this still happens on Firefox, a performance profile from the Firefox profiler would probably be helpful.

Still happens, here's a profile:
https://share.firefox.dev/3MHTA5N

Comment 16

[:Gijs (he/him)]

The profile shows a lot of time spent in glsl::textureLinearUnpackedRGBA8 but I don't know how useful that is to the graphics team, and/or if more salient stuff could be gleaned by someone who actually knows the graphics pipeline...

Comment 17

[davestux]

(In reply to :Gijs (he/him) from comment #16)

The profile shows a lot of time spent in glsl::textureLinearUnpackedRGBA8 but I don't know how useful that is to the graphics team, and/or if more salient stuff could be gleaned by someone who actually knows the graphics pipeline...

I don't know how much this helps, but the webpage I use for testing the issue is:
https://www.gigabyte.com/us/Motherboard/X570-AORUS-MASTER-rev-10/support#dl

Using Chromium over X2GO, Firefox locally or Firefox over VNC, the page rendering performance is OK. With Firefox over X2GO or Firefox over SSH with xserver forwarding the rendering is terrible and after clicking driver or two, which cause redrawing of the tables, Firefox becomes unresponsive.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Based on performance calculator, given that this is quite rare use case, the impact it low.