I don't have a design file to test xcircuit with either. I only used this because it was the first free application that I stumbled upon (after some trial and error) that exhibits this behavior.

In my case, after launching xcircuit from a gnome-terminal in rootless mode, ALL X applications (including the gnome-terminal) running within the x2go session become COMPLETELY unresponsive (e.g. no window redraws/updates) for 5 MINUTES to the point where it almost looks like a total system lockup. However, during this 5 minute freeze of the x2go session, I have no problems running other programs on the host (e.g. from an ssh or VNC session). Also, while my x2go session is apparently frozen, x2go agent is sipping about 0.3% of the CPU. Eventually, after being frozen for 5 minutes, my x2go session recovers and I can interact with the xcircuit application with no apparent delays. Redraws are quick (including when windows are uncovered from beneath other windows) and everything is speedy and responsive.

This really seems like some kind of catastrophic network issue where data is getting lost (e.g. buffer overflows?), and the session won't recover until 1 (or more) timeouts expire. Maybe it doesn't have to do with the client OS at all and is instead a function of network conditions (which would be very difficult to reproduce).

I haven't been able to test this with an x2go client running on Linux because our RHEL repo only has the packages necessary to run the x2go server, not the client.



On Fri, Nov 18, 2016 at 4:38 AM, Aki Ketolainen <akik@mykolab.com> wrote:

On 2016-10-27 21:37, Thomas Esposito wrote:

 > Package: x2goserver
 > Version: 4.0.1.19-3
 > Severity: critical
>
>  Server OS: RHEL6.6
>  Client OS: Windows 7 SP1 64-bit
>  Server Packages: x2goserver-4.0.1.19-3.el6.x86_64
>                             x2goagent-3.5.0.32-3.el6.x86_64
>                             nxagent-3.5.0.31-1.el6.x86_64 (not sure if this is a dependency)
>                              nx-libs-3.5.0.31-1.el6.x86_64 (not sure if this is a dependency)
> Client Version: 4.0.5.2
>
> <cut>
>
> Luckily, I was able to find a free application that is similarly unresponsive when starting up in seamless window mode, but that runs fine in virtual desktop mode: xcircuit. This happens to be a free CAD program for drawing circuit schematics. Obviously, I can't be 100% that this X11 application is failing in the same way as my proprietary EDA tools, but it is something the x2go developers can look at regardless.
>
> http://opencircuitdesign.com/xcircuit/
>
>  <cut>

Hi,

I'm experiencing the same effect than you, but the software applications and operating systems are a bit different.
In my case the slow window redraws happen if:

The client operating system is Ubuntu Linux and the local desktop environment is either Unity,  XFCE or Mate.
If I'm running Ubuntu Linux on the client machine and the local desktop environment is either KDE or LXDE, I don't experience the slow window updates.
I'm running the X2Go server on Azure and it's running CentOS 6.8. The desktop environment on the server is XFCE.

As you also noticed, the slow window updates only happen with the single application mode/seamless window mode.

I haven't tested much with Windows on the client side but the same slow window updates that you can see just by moving terminal windows on top of each other is not there
(when you first open one terminal with single application mode and then open another terminal from the first).

I installed xcircuit on the X2Go server and it starts up and works quite ok, although I don't have any design file to test with.
We are working on the same EDA field so I'm interested in finding a solution to this problem.

Bug reports talking about the slow window updates:
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1010
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1081

Best regards,

Aki