VNC Viewer Win 3.3.3R1 woes

[Quentin Stafford-Fraser]

"Dunn, Rick" wrote:
> 
> I have a Dell Prescision 610 DP 450 Xeon, NT 4 SP5. When I connect to any
> remote system the viewer stops updating the screen shortly after, the remote
> system still recieves the keyboard and mouse OK, I cannot see anything
> though.

Rick, 

Yes, you have the same problem that was mentioned earlier.  It's a
dual-processor machine, right?  It's to do with the changes in the
locking between threads in the viewer, and I obviously need to sort it
out.

For those interested in the internals of the viewer, here's a little
essay:  

VNCviewer has two threads. One of them reads screen updates from the
network and draws them on a bitmap, and the other handles the local GUI
message loop, including menus, scrollbars etc, and also paints to the
screen by blitting from the bitmap when it is informed that new updates
have arrives, or when part of the window is exposed, etc.

There is locking between these threads for two reasons. 

Firstly, there is a mutex which is nominally a lock on the bitmap.  This
shouldn't be needed - it doesn't really matter whether the contents of
the bitmap are being copied to the screen and updated from the network
at the same time, but I wasn't sure whether the other structures
(palletes, brushes, modified region lists, etc) would take so kindly to
multi-threaded use. Anyway, it didn't seem to work as well when I took
it out, though I haven't investigated very deeply.  However, the thing
that has changed in the most recent viewer is the frequency with which
this mutex is held and released. In the old version, the network thread
would grab the mutex, read a complete update from the network, and then
release it. But a 'complete update' could be the whole screen and could
take a long time over a modem.  During this period, if the other thread
received a WM_PAINT message it would stop, waiting for the mutex, and
this would mean that the user couldn't do anything to the window until
the whole update had been received.  So I changed the network thread so
that it would release the mutex from time to time. It now locks it
separately for each row of a hextile update, for example, rather than
for the whole update.  This makes things much better on slow links.

Secondly, the network thread mustn't request another screen update until
it knows the current one has been drawn.  Otherwise it could go round
and round happily reading updates into the bitmap, without the GUI
thread ever getting a chance to draw them on the screen. And, no,
changing the relative priorities of the threads doesn't seem to help. I
admit I don't know much about the internals of the Windows scheduler. 
So it needs to arrange that the updates get painted before it responds.
At the moment it does this by calling UpdateWindow, though I have tried
a couple of other methods.  My guess is that this arrangement doesn't
work with dual-processors.

I'll try to look into it, but any suggestions welcome!

Quentin
-- 
----------------------------
Dr Quentin Stafford-Fraser
AT&T Laboratories Cambridge
http://www.uk.research.att.com/~qsf

---------------------------------------------------------------------
The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------