TODO


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

immediate:
----------

test copyRect and pthreads.
authentification schemes (secure vnc)
udp
documentation
	hint that to mark very tiny regions as
	modified is possibly inefficient for the encodings.
	(a trail of points could be better a small rectangle).

later:
------

autoconf? at least Sun Solaris and Windows compilation
CORBA

done:
-----

.optionally dont draw rich cursors as xcursors
.cursor smears on IRIX with pthreads, then has bus error. has to be a mutex
	problem in cursor routines.
.fix bug in http (java) client with big endian server: byte swapping is broken
	(was a cursorshape which was sent too soon; java vncviewer assumes
	a rich cursor shape to be always 1 byte per pixel, however, framebuffer
	updates before setting the pixel format can be server format)
.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).