>
> 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().
>
I tried those 2 fixes unfortunately they did not work in my case (which
is the same case anyway) - because of the way the TIMER_UPDATE is
invoked. Invoking the TIMER_UPDATE regulary "fixes" the issue however,
it's an ugly work-around.
The way i reproduce it is by opening the Control Center of KDE 3.5x and
clicking on the File menu item, clicking again to make it go away - and
it doesnt until there's an event (mouse move, keystroke, clipboard
notification, etc) even thus the viewer does get a WM_PAINT even already.
The timer trigger a new WM_PAINT which i suppose this time contains the
proper area (or maybe the other one happens too early/for a different
data) and the paint is done.
So basically with a regular timer the viewer works fine, but it's not a
nice solution.
I do have a similar issue with the blockCallback() code with my own client:
My client/server support dynamic live desktop resolution switching, as
in, you resize the client window and the server will change the
resolution to adapt (its very fast and thus works well). However with
the Window client the updates are blocked until the mouse is released
(then it gets all updates at once).I can force the updates in a similar
manner with a timer, but that's not clean either. (oh and I hope to put
that feature into 1.1 btw - its really convenient ;-)
Note that these issues do not happen through e.g. Wine (they do in WinXP
and W7 however).
I would be interested into a clean solution/explanation of this
behavior, if you guys have any idea.
Dirty fix:
diff --git a/win/vncviewer/DesktopWindow.cxx
b/win/vncviewer/DesktopWindow.cxx
index cc40a22..4afa612 100644
--- a/win/vncviewer/DesktopWindow.cxx
+++ b/win/vncviewer/DesktopWindow.cxx
@@ -742,6 +742,11 @@ DesktopWindow::processMessage(UINT msg, WPARAM
wParam, LPAR
LRESULT
DesktopWindow::processFrameMessage(UINT msg, WPARAM wParam, LPARAM
lParam) {
+ /* XXX HACK force updating
+ issue "introduced" with TLS */
+ if (!updateTimer.isActive())
+ updateTimer.start(100);
+
switch (msg) {
// -=- Paint the remote frame buffer
--
Guillaume Destuynder - m-privacy GmbH -
Am Köllnischen Park 1, 10179 Berlin
Tel: +49 30 24342334
Fax: +49 30 24342336
Web: http://www.m-privacy.de, http://oss.m-privacy.de
Handelsregister:
Amtsgericht Charlottenburg HRB 84946
Geschäftsführer:
Dipl.-Kfm. Holger Maczkowsky,
Roman Maczkowsky
GnuPG-Key-ID: 0x3FB1D217
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
