[X2Go-Dev] Bug#1109: Bug#1109: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

[Thomas Esposito]

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 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20161118/ca526ad1/attachment.html>