From tmesposito00@gmail.com Thu Oct 27 20:37:52 2016 Received: (at submit) by bugs.x2go.org; 27 Oct 2016 18:37:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 024225DABA for ; Thu, 27 Oct 2016 20:37:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o3IhsOqLWHX for ; Thu, 27 Oct 2016 20:37:45 +0200 (CEST) Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id A31A95DA91 for ; Thu, 27 Oct 2016 20:37:44 +0200 (CEST) Received: by mail-vk0-f49.google.com with SMTP id d65so7777284vkg.0 for ; Thu, 27 Oct 2016 11:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=96Wve24w6jse+RGWfBJtELgV8sAAv497Z74YBtQ1DH8=; b=ZZU/XUfSpFKM/2wr2HuaiXFwTaY5ojjVRhAqHRSnEytlULOb9mzmRtYzIAICN48iuL TGmLORe+aOAZAEiHJK0porC/6uaQbx6HUcJuLAwqeCh1Ki0DCfv2zilRXKL+cRfspfPb CTRuktIvv5QYYi6qXLeH7DbwFESnvI3gp9Uo+cvLriv22/lngXStILNbxYIjvPuCMroo NspD5uyP29Cc+56xEWoe7Me7RJvYms+mhRTslfaKr0ouzOTdNFKhjS0YTtL1sk+ZIQPG okgr/NBdkoPYTXwkune1ohUXyR0IubLFhegrXDeLBmu7GYCeKxNpyitZrwJZH6iMlVOn GqXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=96Wve24w6jse+RGWfBJtELgV8sAAv497Z74YBtQ1DH8=; b=mCIH0Mjv9NXyyb8LqsJNa7+HnGTTB765iZfawSh9cP90oT6/fZ5nbn05BPGjXpUw9h njvJkhtds2b4vIPfKtd6BgxYZZAmJkMfSHpXTA42rs+MZT3hIYvoIA1FpLF8/WMzp29N tHIszvpm50H63RP0Xc0GSMyD7AbJ6gTPYDdjCWw0l/LUiZ9eoTzqwsvru3suWzIAoKRV 3TdkuzPnZPF37gOHOfaTeR1uw52jSFvUDKOeULdEU2N8uUrEIRwxj1Cv/XSFjZvF13ur DpwM6ccqsk22IINWH+AlxkNSXZpA9javF2cBq8dniq8NaiYlzVGFbtBck5lu3hyqW4Do lhfw== X-Gm-Message-State: ABUngveT6XBSGlelGFFg7eE+N9igk48FgtmrOcsbQ5f9QJeI6TiaG9TyXFsMJ3zOVKAfWE0He+L2Hsa1yTkfVg== X-Received: by 10.31.93.198 with SMTP id r189mr3634436vkb.39.1477593463096; Thu, 27 Oct 2016 11:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.130 with HTTP; Thu, 27 Oct 2016 11:37:42 -0700 (PDT) From: Thomas Esposito Date: Thu, 27 Oct 2016 14:37:42 -0400 Message-ID: Subject: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode To: submit@bugs.x2go.org Content-Type: multipart/alternative; boundary=94eb2c0949cc7d8a83053fdd0900 --94eb2c0949cc7d8a83053fdd0900 Content-Type: text/plain; charset=UTF-8 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. --94eb2c0949cc7d8a83053fdd0900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Package: x2goserver
<= div style=3D"font-size:12.8px">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
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x2goagent-3.5.0.32-3= .el6.x86_64
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nxagent-3.5.0.31-1.el6.x86_64 (not sure if this is a dependency)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nx-libs-3.5.0.31-1.e= l6.x86_64 (not sure if this is a dependency)
Client Version: 4.0.5.2

This only occurs when starting a termina= l in seamless window mode, and then launching the "problem" appli= cations from that terminal. I imagine that I'd observe the same behavio= r if launching the application directly when the x2go session is created.

Certain applications experience catastrophically long delays (i.e. unres= ponsive for several minutes) during startup and even more so during reconne= ct (after a session is suspended). In particular, this happens with 2 Synop= sys 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&#= 39;t use a lot of other modern X client-side rendering techniques.=C2=A0

Luckily, I was able to find a free application that is similarly unrespon= sive when starting up in seamless window mode, but that runs fine in virtua= l desktop mode:=C2=A0xcircuit. This happens to be a free CAD program= for drawing circuit schematics. Obviously, I can't be 100% that this X= 11 application is failing in the same way as my proprietary EDA tools, but = it is something the x2go developers can look at regardless.


In order to diagnose the problem, I ran my app= lications under xtrace with the '--relative-timestamps' option in o= rder to see the kind of X11 protocol traffic that was being generated. In b= oth 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 TO= N on individual rectangle primitives. If I filter the log file dumped out b= y xtrace to just show timestamps, I see HUGE jumps/discontinuities where th= ere are several seconds or even minutes of apparent inactivity between cons= ecutive messages. According to top, x2goagent is NOT consuming an excessive= amount of CPU during these period of unresponsiveness.

I don't kno= w much about the details of the X11 protocol, but it almost seems as if the= re is some kind of message buffer overrunning somewhere causing things to g= et out of sync, only recovering after some kind of watchdog or timeout mech= anism 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 betwee= n seamless window mode and virtual desktop mode is that when reconnecting a= fter a suspend, seamless windows are probably going to see a lot more event= s from the server (e.g. expose events, window manipulation notifications, e= tc.) because of interactions with the locally running windows which may be = in a totally different state compared to when the x2go session was suspende= d. In contrast, when running in a virtual desktop, the applications are con= tained with a "box" that isolates it from the state of the local = windows on the x2go client side.

<= /div>
It is important to note that, for all = of the applications that exhibit this behavior, once the application has st= arted up (or after suffering long delays during an x2go reconnect), the app= lication is perfectly functional and responsive.=C2=A0
--94eb2c0949cc7d8a83053fdd0900--