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

From: Ulrich Sibiller <[email-masked]>
Date: Wed, 16 Nov 2016 22:42:35 +0100

On Thu, Oct 27, 2016 at 8:37 PM, Thomas Esposito <[email-masked]> 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
>
> This only occurs when starting a terminal in seamless window mode, and then
> launching the "problem" applications from that terminal. I imagine that I'd
> observe the same behavior if launching the application directly when the
> x2go session is created.
>
> Certain applications experience catastrophically long delays (i.e.
> unresponsive for several minutes) during startup and even more so during
> reconnect (after a session is suspended). In particular, this happens with 2
> Synopsys EDA (Electronic Design Automation) applications that I heavily rely
> on, dve and verdi. Obviously, you won't be able to test these because they
> require an expensive license, but I can tell you that they are older-style
> X11 applications that user X server-side font rendering and probably don't
> use a lot of other modern X client-side rendering techniques.
>
> 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/
>
> In order to diagnose the problem, I ran my applications under xtrace with
> the '--relative-timestamps' option in order to see the kind of X11 protocol
> traffic that was being generated. In both cases (i.e. my Synopsys EDA
> applications and xcircuit), there appear to be MASSIVE amounts of
> notifications and events going from the X server to the X client. It seems
> like the application's window is made up of a TON on individual rectangle
> primitives. If I filter the log file dumped out by xtrace to just show
> timestamps, I see HUGE jumps/discontinuities where there are several seconds
> or even minutes of apparent inactivity between consecutive messages.
> According to top, x2goagent is NOT consuming an excessive amount of CPU
> during these period of unresponsiveness.
>
> I don't know much about the details of the X11 protocol, but it almost seems
> as if there is some kind of message buffer overrunning somewhere causing
> things to get out of sync, only recovering after some kind of watchdog or
> timeout mechanism kicks in. If my theory is correct and this happens
> repeatedly, it can add up to MINUTES of unresponsiveness. However, I'm not
> sure why this would happen only in seamless window mode. Certainly, one
> difference between seamless window mode and virtual desktop mode is that
> when reconnecting after a suspend, seamless windows are probably going to
> see a lot more events from the server (e.g. expose events, window
> manipulation notifications, etc.) because of interactions with the locally
> running windows which may be in a totally different state compared to when
> the x2go session was suspended. In contrast, when running in a virtual
> desktop, the applications are contained with a "box" that isolates it from
> the state of the local windows on the x2go client side.
>
> It is important to note that, for all of the applications that exhibit this
> behavior, once the application has started up (or after suffering long
> delays during an x2go reconnect), the application is perfectly functional
> and responsive.

This looks like a problem of nx. Can you please try this:
1. run /usr/bin/nxagent -R -ac :5   (you'll see nothing)
2. launch the problematic application:
export DISPLAY=:5
/usr/bin/problematic-app
3. kill -HUP <pid of nxagent> (suspend session)
4. wait some seconds
5. kill -HUP <pid of nxagent> (resume session)

Does this also show the delays? (it doesn't for me with xcircuit, but
I seem to have
some font trouble here. I get lots of 'Error:  font encoding file
missing for font "Helvetica"' messages).

Uli