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 20000 when tested earlier...) Has freezing issue
> in TLS
> Tight: 19000kbps or greater. Has freezing issue in TLS
> Hextile: 20000 kbps. Has freezing issue in TLS
> Raw: 20000 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
