Re: [Tigervnc-devel] Peculiar Refresh Issue with TLS
Good work digging into this problem. I am glad to hear this is only
a Windows problem. It confirms my limited testing of this issue on
other platforms. Do you have any preferences of the two solutions?
Robert
On 02/26/2011 12:42 PM, Martin Koegler wrote:
The problem is, that the viewer is (for windows) too busy for
delivering the WM_PAINT. TLS seems to be a reliable trigger, but it
should be possible to construct work loads for the non-TLS case too,
where the screen updates are stalled.
How can it be fixed:
1) The situation can be improved, if in win/vncviewer/CConn.cxx the priority of
the Windows events is raised:
In CConn::blockCallback():
// Wait for socket data, or a message to process
DWORD result = MsgWaitForMultipleObjects(1, sockEvent.h, FALSE, INFINITE, QS_ALLINPUT);
if (result == WAIT_OBJECT_0) {
// - Network event notification. Return control to I/O routine.
break;
} else if (result == WAIT_FAILED) {
// - The wait operation failed - raise an exception
throw rdr::SystemException("blockCallback wait error", GetLastError());
}
// - There should be a message in the message queue
MSG msg;
while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) {
// IMPORTANT: We mustn't call TranslateMessage() here, because instead we
// call ToAscii() in CKeyboard::keyEvent(). ToAscii() stores dead key
// state from one call to the next, which would be messed up by calls to
// TranslateMessage() (actually it looks like TranslateMessage() calls
// ToAscii() internally).
DispatchMessage(msg);
}
=
// Wait for socket data, or a message to process
DWORD result = MsgWaitForMultipleObjects(1, sockEvent.h, FALSE, INFINITE, QS_ALLINPUT);
if (result == WAIT_FAILED) {
// - The wait operation failed - raise an exception
throw rdr::SystemException("blockCallback wait error", GetLastError());
}
MSG msg;
while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) {
// IMPORTANT: We mustn't call TranslateMessage() here, because instead we
// call ToAscii() in CKeyboard::keyEvent(). ToAscii() stores dead key
// state from one call to the next, which would be messed up by calls to
// TranslateMessage() (actually it looks like TranslateMessage() calls
// ToAscii() internally).
DispatchMessage(msg);
}
if (result == WAIT_OBJECT_0) {
// - Network event notification. Return control to I/O routine.
break;
}
2) Add regular explicit calls to UpdateWindow(hWnd) to force an immediate update.
Maybe in DesktopWindow::processMessage, case WM_TIMER after the call
to updateWindow().
--
Robert Goley
FOSS
Implementation Specialist
Toll Free: (800) 338-4984
Local: (770) 479-7933
Fax: (770) 479-4076
www.openrda.com
America's only Free Open Source
fund accounting software company.
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Peculiar Refresh Issue with TLS
On Fri, Feb 25, 2011 at 07:06:39PM -0500, Robert Goley wrote:
Here are the results from using the different encodings:
OpenBox Window Manager:
ZLRE: 11428 kbs (Server has a little load at the moment,
this was around 2 when tested earlier...)Has freezing issue
in TLS
Tight: 19000kbps or greater.Has freezing issue in TLS
Hextile:2 kbps.Has freezing issue in TLS
Raw:2 kbps.Has freezing issue in TLS
For reference, I am getting the same results using the Motif Window
Manager (MWM). I used it for testing because they really don't come
much simpler other than TWM...
As far as I can tell, it looks like a problem in the Windows vncviewer:
The windows viewer keeps updating its internal frame buffer and call
invalidate_modifed regions of the window with InvalidateRect
(win/vncviewer/DesktopWindow.cxx DesktopWindow::updateWindow).
With InvalidateRect windows is free to send the WM_PAINT message, when
it thinks, that the application has time for it. When this WM_PAINT
messages is delivered by windows, the content of the windows is
updated.
For the viewer, all server messages have the highest priority,
followed by the various windows messages. The least priority has
WM_PAINT.
The problem is, that the viewer is (for windows) too busy for
delivering the WM_PAINT. TLS seems to be a reliable trigger, but it
should be possible to construct work loads for the non-TLS case too,
where the screen updates are stalled.
How can it be fixed:
1) The situation can be improved, if in win/vncviewer/CConn.cxx the priority of
the Windows events is raised:
In CConn::blockCallback():
// Wait for socket data, or a message to process
DWORD result = MsgWaitForMultipleObjects(1, sockEvent.h, FALSE, INFINITE,
QS_ALLINPUT);
if (result == WAIT_OBJECT_0) {
// - Network event notification. Return control to I/O routine.
break;
} else if (result == WAIT_FAILED) {
// - The wait operation failed - raise an exception
throw rdr::SystemException(blockCallback wait error, GetLastError());
}
// - There should be a message in the message queue
MSG msg;
while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) {
// IMPORTANT: We mustn't call TranslateMessage() here, because instead we
// call ToAscii() in CKeyboard::keyEvent(). ToAscii() stores dead key
// state from one call to the next, which would be messed up by calls to
// TranslateMessage() (actually it looks like TranslateMessage() calls
// ToAscii() internally).
DispatchMessage(msg);
}
=
// Wait for socket data, or a message to process
DWORD result = MsgWaitForMultipleObjects(1, sockEvent.h, FALSE, INFINITE,
QS_ALLINPUT);
if (result == WAIT_FAILED) {
// - The wait operation failed - raise an exception
throw rdr::SystemException(blockCallback wait error, GetLastError());
}
MSG msg;
while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) {
// IMPORTANT: We mustn't call TranslateMessage() here, because instead we
// call ToAscii() in CKeyboard::keyEvent(). ToAscii() stores dead key
// state from one call to the next, which would be messed up by calls to
// TranslateMessage() (actually it looks like TranslateMessage() calls
// ToAscii() internally).
DispatchMessage(msg);
}
if (result == WAIT_OBJECT_0) {
// - Network event notification. Return control to I/O routine.
break;
}
2) Add regular explicit calls to UpdateWindow(hWnd) to force an immediate
update.
Maybe in DesktopWindow::processMessage, case WM_TIMER after the call
to updateWindow().
Regards,
Martin Kögler
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Peculiar Refresh Issue with TLS
Are you using a compositing window manager by chance? I noticed a similar issue with my installation of Gnome, and I think it was related to me having tried to get it working with compiz earlier. I didn't have time to look into it, so I just punted and switched to KDE for now. :) Don't know why it would only be happening with TLS, though. It may not even be the same issue as what I was seeing. On 2/25/11 2:29 PM, Robert Goley wrote: I have been doing more testing with the binaries DRC provided. Thanks for those btw. For the most part, these are working great. I have noticed that most of the time when I use them and connect using TLSPlain or TLSVnc that I get freezes in the screen refreshes. For example, when running a program that I know is constantly updating the screen, the screen will only update when I move the mouse. I am not talking about small delays either. It will not update the screen for minutes then I move the mouse and the entire screen updates for me to see the command has entirely completed. Think of creating a tarball of a larger directory where the command with take a couple of minutes, run the command and then do not move the mouse for several minutes then moving it to see the command completed. It is really annoying for little things like that. It does not happen when running in Plain or VncAuth modes, just in TLS ones. I am connecting over a gigabit ethernet where client and server both support gigabit connections.When connecting using TLS, it uses the Tight extension and gets a line speed of 2 kbps. It shows those same rates for non TLS connections. It is kind of funny to watch because the screen will update fine as long as I move the mouse. It freezes instantly when the mouse stops too. Anyone got any ideas on this? It did not seem to do this prior to all the performance improvement patches for GL but I am not sure if this would be related. -- *Robert Goley* FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com /America's only Free Open Source fund accounting software company./ -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Peculiar Refresh Issue with TLS
On Fri, Feb 25, 2011 at 03:35:39PM -0600, DRC wrote: Are you using a compositing window manager by chance? I noticed a similar issue with my installation of Gnome, and I think it was related to me having tried to get it working with compiz earlier. I didn't have time to look into it, so I just punted and switched to KDE for now. :) Don't know why it would only be happening with TLS, though. It may not even be the same issue as what I was seeing. On 2/25/11 2:29 PM, Robert Goley wrote: I have been doing more testing with the binaries DRC provided. Thanks for those btw. For the most part, these are working great. I have noticed that most of the time when I use them and connect using TLSPlain or TLSVnc that I get freezes in the screen refreshes. For example, when running a program that I know is constantly updating the screen, the screen will only update when I move the mouse. I am not talking about small delays either. It will not update the screen for minutes then I move the mouse and the entire screen updates for me to see the command has entirely completed. Think of creating a tarball of a larger directory where the command with take a couple of minutes, run the command and then do not move the mouse for several minutes then moving it to see the command completed. It is really annoying for little things like that. It does not happen when running in Plain or VncAuth modes, just in TLS ones. I am connecting over a gigabit ethernet where client and server both support gigabit connections.When connecting using TLS, it uses the Tight extension and gets a line speed of 2 kbps. It shows those same rates for non TLS connections. It is kind of funny to watch because the screen will update fine as long as I move the mouse. It freezes instantly when the mouse stops too. Anyone got any ideas on this? It did not seem to do this prior to all the performance improvement patches for GL but I am not sure if this would be related. What client/server combination are you using? I can repoduce this (KDE desktop on server, win client, TLS) - but only using the tight encoding. ZRLE with TLS is fine. I can't reproduce it with KDE desktop to linux client. I'll try to further analyse the problem. Regards, Martin Kögler -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Peculiar Refresh Issue with TLS
I am reposting my reply to DRC which answered Martin's questions too. I replied directly to him and thought I had done it to the list... I am using the openbox window manager with the taskbar from the LXDE project. Very simple windowing environment. I do not know about the compositing features though. I did not think it was using any. I will dig into that a bit and let you know. I should also mention I am using the Windows viewer from a Windows XP Pro SP3 machine to connect to a Debian Lenny 64 bit server. Both machines are using DRC's binaries. I it defaults to using Tight encodings. Robert On 02/25/2011 05:33 PM, Martin Koegler wrote: On Fri, Feb 25, 2011 at 03:35:39PM -0600, DRC wrote: Are you using a compositing window manager by chance? I noticed a similar issue with my installation of Gnome, and I think it was related to me having tried to get it working with compiz earlier. I didn't have time to look into it, so I just punted and switched to KDE for now. :) Don't know why it would only be happening with TLS, though. It may not even be the same issue as what I was seeing. On 2/25/11 2:29 PM, Robert Goley wrote: I have been doing more testing with the binaries DRC provided. Thanks for those btw. For the most part, these are working great. I have noticed that most of the time when I use them and connect using TLSPlain or TLSVnc that I get freezes in the screen refreshes. For example, when running a program that I know is constantly updating the screen, the screen will only update when I move the mouse. I am not talking about small delays either. It will not update the screen for minutes then I move the mouse and the entire screen updates for me to see the command has entirely completed. Think of creating a tarball of a larger directory where the command with take a couple of minutes, run the command and then do not move the mouse for several minutes then moving it to see the command completed. It is really annoying for little things like that. It does not happen when running in Plain or VncAuth modes, just in TLS ones. I am connecting over a gigabit ethernet where client and server both support gigabit connections.When connecting using TLS, it uses the Tight extension and gets a line speed of 2 kbps. It shows those same rates for non TLS connections. It is kind of funny to watch because the screen will update fine as long as I move the mouse. It freezes instantly when the mouse stops too. Anyone got any ideas on this? It did not seem to do this prior to all the performance improvement patches for GL but I am not sure if this would be related. What client/server combination are you using? I can repoduce this (KDE desktop on server, win client, TLS) - but only using the tight encoding. ZRLE with TLS is fine. I can't reproduce it with KDE desktop to linux client. I'll try to further analyse the problem. Regards, Martin Kgler -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Robert Goley FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com America's only Free Open Source fund accounting software company. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
