immediate:
----------
fix bug in http (java) client with big endian server: byte swapping is broken
udp
documentation
perhaps the option (or just hint) not to mark very tiny regions as
modified, because that is inefficient for the encodings.
optionally dont draw rich cursors as xcursors
later:
------
autoconf? at least Sun Solaris and Windows compilation
CORBA
cursor "smears" sometimes when not using cursor encoding
(seems to be gone now; haven't debugged properly, though)
done:
-----
.rfbConnect, ConnectToTcpAddr
.update to newest TridiaVNC version (1.2.1).
.adapt rdp2vnc (rdesktop)
.pthreads concept: How to iterate over rfbClientPtr's? So that it can be
either called from rfbProcessEvents (which locks the list mutex)
or from the main thread (where the background loop sometimes
locks the list mutex).
- cursor drawing!
- cursor setting!
- rfbMarkRectAsModified
(did that by adding a refcount to clients secured by refCountMutex;
it also was necessary to check for cl->sock<0 in SendUpdateBuf)
.translate.c: warning about non 8-bit colourmaps
16-bit colourmaps are 192k -> no use without fast net.
.rfbCloseClient
.set colourmap
.support 3 bytes per pixel
.cursors
.cutpaste
.httpd
.other encodings
.test drawing of cursors when not using xcursor or rich cursor encoding
fix bug with odd width (depends on client depth: width has to be multiple of server.bytesPerPixel/client.bytesPerPixel). only raw!! -> bug of vncviewer!
.use sraRegion from Wez instead of miregion, because it is much smaller
. - connection gone and then reconnect is a problem
the reason: there are in fact three threads accessing
the clientPtr: input, output and the application thread.
if you kill the viewer or do rfbCloseClient, all of those
three have to be warned that this is happening.
-> rfbClientConnectionGone can only be called by the outer loop
(with background loop, it is input, else it is processEvents).
