Bug 1172337 - GTK3 apps have huge rendering stalls over SSH connection
Summary: GTK3 apps have huge rendering stalls over SSH connection
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk3
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1419212
TreeView+ depends on / blocked
 
Reported: 2014-12-09 21:15 UTC by Robert Hancock
Modified: 2017-02-03 23:33 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
: 1243646 1419212 (view as bug list)
Environment:
Last Closed: 2015-09-02 22:15:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
output from xtrace on gedit, working case (1.16 MB, text/plain)
2014-12-19 20:28 UTC, Robert Hancock
no flags Details
output from xtrace on gedit, broken case (1.16 MB, text/plain)
2014-12-19 20:29 UTC, Robert Hancock
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 741800 0 None None None Never

Description Robert Hancock 2014-12-09 21:15:41 UTC
Description of problem:
I have a CentOS 7 virtual machine running under KVM on my local machine running F21 with Intel Haswell-based integrated graphics. I'm connecting into the VM via "ssh -X" and running some graphical applications. For some reason, some apps run incredibly slowly under this setup. For example, if you start up gedit and start typing some characters, the whole window seems to mostly stall for 30-60 seconds at a time. Eclipse also exhibits these huge pauses.

This problem did not occur when I was using a Scientific Linux 6 VM from the Fedora host. I tested it with a Fedora 20 VM as well and it had the same issue. Strangely enough, connecting into a CentOS 7 physical machine over the network didn't seem to have this problem, the GUI was responsive.

It seems like the combination of an F20/F21 host OS, modern Gnome 3-based guest, and connecting into the guest via SSH is what causes the problem. Based on the network traffic showing up in ifconfig on the guest, during these pauses there's hardly any traffic going across the network connection, so I don't think it's just bottlenecked on network bandwidth (not that this should be an issue anyways with a local connection). My only real theory at this point is that the particular timing of the SSH connection to a local VM is somehow causing issues.

It appears that some apps are affected more than others. The problem is quite apparent with gedit and gnome-calculator. Some others like gvim, however, have hardly any issues.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.16.2-1.fc21.x86_64

How reproducible:
Every time (for me anyway)

Steps to Reproduce:
1. Create and start up CentOS 7 KVM virtual machine (or Fedora 20 VM also seems to work) using NAT networking
2. ssh -X into VM using its NAT IP address (192.168.122.x) and run gedit
3. Type, open files, etc. in gedit

Actual results:
GUI stops responding for 30-60 second intervals.

Expected results:
GUI responds properly.

Additional info:
I have no idea if the X server is the cause of the problem, or whether the issue is even in the host and not the guest OS, but I wasn't sure where else to report this.

Comment 1 Robert Hancock 2014-12-11 17:22:44 UTC
It looks like this does not only affect connections to a local VM, but connections to another real computer over the network as well. I have been able to reproduce this by running gedit over an SSH connection from two computers running F21, both of which use Intel Haswell-based integrated graphics. On another F21 machine that used Nvidia graphics with the nouveau driver, I was NOT able to reproduce the problem.

So from what I can tell this problem seems to be graphics driver dependent, though it's still possible that this is a red herring.

Comment 2 Robert Hancock 2014-12-11 17:26:07 UTC
And the CentOS 7 part was also not relevant, as F21->F21 SSH connections have the same issue.

Comment 3 Robert Hancock 2014-12-19 20:28:28 UTC
Created attachment 971305 [details]
output from xtrace on gedit, working case

Comment 4 Robert Hancock 2014-12-19 20:29:00 UTC
Created attachment 971306 [details]
output from xtrace on gedit, broken case

Comment 5 Robert Hancock 2014-12-19 20:40:31 UTC
I've attached the output of two test cases for this. Each involves logging into a CentOS 7 machine on the network with ssh -X, then running gedit under xtrace to capture all of the X events, and typing some characters into the window. In the working case, gedit works normally. In the failing case, gedit basically stops rendering after the first key is pressed and the text window doesn't update (though it still responds to the close button).

I have no idea why it consistently works on the one machine but fails on the other. The only difference I can see is that the machine I'm logging into in the working case is a fair bit slower. The faster machine is the one where gedit doesn't work properly. There also appear to be some ordering differences between the two files: in the working one, when the program sends requests to change the window title properties after the first key is pressed (to add the star to the title), it takes 7ms to get the PropertyNotify messages back (after a bunch of other render requests have already been sent), whereas in the broken case, it only took 1ms and there are very few rendering requests sent back after that. I'm wondering if one of these timing differences is causing the problem.

It also seems to be GTK3 apps specifically which have issues. So far, it appears that gedit and virt-manager have issues, but gvim (vim-X11), which uses gtk2, seems unaffected. So I'm reassigning this to gtk3.

Comment 6 Robert Hancock 2014-12-23 17:20:12 UTC
Also reported upstream. No response there either though.

Comment 7 Robert Hancock 2015-05-29 15:35:42 UTC
Still occurring in F22.

Comment 8 Robert Hancock 2015-07-16 02:43:04 UTC
Said to be fixed in gtk3 git:

https://git.gnome.org/browse/gtk+/commit/?id=6504b2e53468004c7936e7f79fba03291dc58128

Comment 9 Michael Stahl 2015-09-02 22:15:48 UTC
with current packages in Fedora 21 and Fedora 22 this now works for me:

gtk3-3.14.15-1.fc21.x86_64

gtk3-3.16.6-1.fc22.x86_64


Note You need to log in before you can comment on or make changes to this bug.