I suppose I'll cover this one next as John Williams raised one of the issues. This is another Windows only issue.
This issue has two categories. It is complicated by the packing problem because we can only run the Windows client now with sub-optimal packing but it was a problem before the corruption issue struck.
Screen painting is just slower - not just a little slower - a lot slower. The typical anecdotal test I've been using is scrolling through my Evolution Inbox. Evolution has always seemed to have terrible graphics handling. I don't know what it does but it is always sluggish and awkward - thus an excellent test of how well we handle challenging graphics.
Even under Linux on a LAN, scrolling is miserably slow. Shift down arrow and wait 1/4 second for a response. This is really annoying. However, in Windows, it is wait 1/2 to 3/4 seconds for a response. This takes it from annoying to dangerous as users wind up deleting or opening unintended emails, i.e., the hold the shift down arrow until they think they have highlighted the mails they want and then press enter. What they don't realize is that five more emails will be selected because of the delay between what they see and the key buffer.
The other problem is a show stopper but I'm not sure it is an X2Go issue. I think this is the same issue John Williams is seeing. We see it only in Windows and Iceweasel. It appears that Iceweasel hangs for quite a long time - not just a few seconds. My guess is 30 seconds to a minute or more. The system is really not hung. All other applications work fine and the screen paints normally. It is just the Iceweasel screen which does not paint. Then, all at once, all the keystrokes and clicks are suddenly executed. It's as if the events are being buffered or stored and not sent.
Although we cannot rule it out, we think we have only seen this in a single scenario - when using the Zimbra web client chat feature. All other browsing and multi-tab activity seems to be fine but, as soon as someone sends me a chat message, Iceweasel painting stops . . . some of the time. Other times it works perfectly fine. Once, it gave me a white screen of death. Another time, it completely killed vcxsrv. Most of the time, it causes this event execution delay. I can merrily go and use other applications and all events are processed with no noticeable delay; I just can use Iceweasel. Then, everything catches up, all the events are processed, and all is well with the world once again.
Zimbra is a heavy AJAX application. I don't know if the application John Williams is using is also heavily AJAX driven - John
I suppose I'll cover this one next as John Williams raised one of the issues. This is another Windows only issue.
This issue has two categories. It is complicated by the packing problem because we can only run the Windows client now with sub-optimal packing but it was a problem before the corruption issue struck.
Screen painting is just slower - not just a little slower - a lot slower. The typical anecdotal test I've been using is scrolling through my Evolution Inbox. Evolution has always seemed to have terrible graphics handling. I don't know what it does but it is always sluggish and awkward - thus an excellent test of how well we handle challenging graphics.
Even under Linux on a LAN, scrolling is miserably slow. Shift down arrow and wait 1/4 second for a response. This is really annoying. However, in Windows, it is wait 1/2 to 3/4 seconds for a response. This takes it from annoying to dangerous as users wind up deleting or opening unintended emails, i.e., the hold the shift down arrow until they think they have highlighted the mails they want and then press enter. What they don't realize is that five more emails will be selected because of the delay between what they see and the key buffer.
The other problem is a show stopper but I'm not sure it is an X2Go issue. I think this is the same issue John Williams is seeing. We see it only in Windows and Iceweasel. It appears that Iceweasel hangs for quite a long time - not just a few seconds. My guess is 30 seconds to a minute or more. The system is really not hung. All other applications work fine and the screen paints normally. It is just the Iceweasel screen which does not paint. Then, all at once, all the keystrokes and clicks are suddenly executed. It's as if the events are being buffered or stored and not sent.
Although we cannot rule it out, we think we have only seen this in a single scenario - when using the Zimbra web client chat feature. All other browsing and multi-tab activity seems to be fine but, as soon as someone sends me a chat message, Iceweasel painting stops . . . some of the time. Other times it works perfectly fine. Once, it gave me a white screen of death. Another time, it completely killed vcxsrv. Most of the time, it causes this event execution delay. I can merrily go and use other applications and all events are processed with no noticeable delay; I just can use Iceweasel. Then, everything catches up, all the events are processed, and all is well with the world once again.
Zimbra is a heavy AJAX application. I don't know if the application John Williams is using is also heavily AJAX driven - John
_<snip> I can confirm that the browser problem ONLY happens when using X2Go. I was able to run for quite a long time in Windows only chatting away on
On Fri, 2011-07-22 at 00:26 -0400, John A. Sullivan III wrote: the Zimbra web client chat service. Not a single problem or delay. It is nearly unusable under X2Go - John
On Thu, Jul 21, 2011 at 9:26 PM, John A. Sullivan III
Zimbra is a heavy AJAX application. I don't know if the application John Williams is using is also heavily AJAX driven - John
The problem occurs most often for me when a gmail tab was open. I think gmail uses AJAX, so AJAX may be the crux of the problem. The problem NEVER occurs for me with x2goclient 3.01-13. It frequently occurs with 3.99 when a gmail tab is open in firefox.
Slightly different than the problem you described is that for me, while it is USUALLY limited to firefox freezing while the other applications continue to work, sometimes it can get into a state where the other applications freeze as well. But not always. And suspending the session from 3.99 and installing 3.01-13 and resuming the session eliminates the freezes. So it is definitely 3.99 that is at the root of the problem.
On Fri, 2011-07-22 at 06:46 -0700, John Williams wrote:
On Thu, Jul 21, 2011 at 9:26 PM, John A. Sullivan III
Zimbra is a heavy AJAX application. I don't know if the application John Williams is using is also heavily AJAX driven - John
The problem occurs most often for me when a gmail tab was open. I think gmail uses AJAX, so AJAX may be the crux of the problem. The problem NEVER occurs for me with x2goclient 3.01-13. It frequently occurs with 3.99 when a gmail tab is open in firefox.
Slightly different than the problem you described is that for me, while it is USUALLY limited to firefox freezing while the other applications continue to work, sometimes it can get into a state where the other applications freeze as well. But not always. And suspending the session from 3.99 and installing 3.01-13 and resuming the session eliminates the freezes. So it is definitely 3.99 that is at the root of the problem. They may still be the same. Most of the time, just Iceweasel is frozen for us but, as I mentioned, once it white screened and other time it killed vcxsrv. If it has the potential to mangle the underlying X server, could that explain whey it sometimes appears to hang the entire session for you?
On Fri, 2011-07-22 at 00:26 -0400, John A. Sullivan III wrote:
I suppose I'll cover this one next as John Williams raised one of the issues. This is another Windows only issue.
This issue has two categories. It is complicated by the packing problem because we can only run the Windows client now with sub-optimal packing but it was a problem before the corruption issue struck.
Screen painting is just slower - not just a little slower - a lot slower. The typical anecdotal test I've been using is scrolling through my Evolution Inbox. Evolution has always seemed to have terrible graphics handling. I don't know what it does but it is always sluggish and awkward - thus an excellent test of how well we handle challenging graphics.
Even under Linux on a LAN, scrolling is miserably slow. Shift down arrow and wait 1/4 second for a response. This is really annoying. However, in Windows, it is wait 1/2 to 3/4 seconds for a response. This takes it from annoying to dangerous as users wind up deleting or opening unintended emails, i.e., the hold the shift down arrow until they think they have highlighted the mails they want and then press enter. What they don't realize is that five more emails will be selected because of the delay between what they see and the key buffer.
<snip> Ugh! Make that 2 to 3 seconds between down arrow and response!!!!
I tried to resume a session I had suspended from Linux but it complained about a mismatched color depth. I checked my Windows laptop and, indeed, it was set to 16 bit color. I changed it to 32 bit color and performance has gone through the floor - John
On Fri, 2011-07-22 at 10:30 -0400, John A. Sullivan III wrote:
On Fri, 2011-07-22 at 00:26 -0400, John A. Sullivan III wrote:
I suppose I'll cover this one next as John Williams raised one of the issues. This is another Windows only issue.
This issue has two categories. It is complicated by the packing problem because we can only run the Windows client now with sub-optimal packing but it was a problem before the corruption issue struck.
Screen painting is just slower - not just a little slower - a lot slower. The typical anecdotal test I've been using is scrolling through my Evolution Inbox. Evolution has always seemed to have terrible graphics handling. I don't know what it does but it is always sluggish and awkward - thus an excellent test of how well we handle challenging graphics.
Even under Linux on a LAN, scrolling is miserably slow. Shift down arrow and wait 1/4 second for a response. This is really annoying. However, in Windows, it is wait 1/2 to 3/4 seconds for a response. This takes it from annoying to dangerous as users wind up deleting or opening unintended emails, i.e., the hold the shift down arrow until they think they have highlighted the mails they want and then press enter. What they don't realize is that five more emails will be selected because of the delay between what they see and the key buffer.
<snip> Ugh! Make that 2 to 3 seconds between down arrow and response!!!!
I tried to resume a session I had suspended from Linux but it complained about a mismatched color depth. I checked my Windows laptop and, indeed, it was set to 16 bit color. I changed it to 32 bit color and performance has gone through the floor - John
<snip> Hmm . . . more important information. It almost looks like the events are being buffered. For example, if I arrow and wait, arrow, wait, arrow, wait, arrow wait - each arrow takes about 2-3 seconds for a screen response. If I arrow, arrow, arrow, arrow, the first screen response takes 2-3 seconds, then, 2-3 seconds later, all the other arrow events are processed.
Are we disabling the Nagle algorithm on all the sockets we open? We should if we are not. Otherwise, we can see this kind of buffering effect. I don't know why that would cause such a change between 16 and 32 bit. Just a thought - John
-
John A. Sullivan III -
John Williams