wishlist : parallelism in vnc transmissions, selective display transfer

[Bob Arctor]

hello.
here is my wishlist/suggestions to vnc development team:
1)multithreaded design. 
let's say user forks 1000x1000 display area. 
it would be nice if it could be splited in i.e. four
500x500 tasks (best would be fork & pipe, but linux ptheads
(which would run on SMP system ) would be fine too

2)multitrheaded client support
let's say user connects to 1000x1000 Xvnc server using 
four 500x500 clients. each connection should be a fork(or next
thread) so :
 -each thread/fork could be re-niced depending on needs 
 -only 500x500 area would be sent to each client (currently
  _whole display is sent_ which is serious misunderstanding.
 -each thread/fork would be handled by separate cpu or 
  migrated away if Xvnc would be started on an cluster

3)Xvnc server and Xvnc encoding processes should be separate processes.
 this is covered by above two points

i know those require major re-writing of Xvnc but they seem to 
be a must, Xvnc is bit obsolete without those features...

4)head-tracking system support for vncviewers and ablity to 
'skip frames' when cpu busy/head tracking system shows us 
that head of an user is not directed toward terminal (
this is really simple - mere infrared LED on head of an user,
and IR photosensor on the terminal... ) 
dpms/apm sensing of vncviewer (so it would 'suspend' transmiision
(if above points about multithreading would be fullfilled 
it would be very simple - just reduce 'requested' screen size
to 8x8 pixels or such ) - it might just stop requesting 
refresh, like x2vnc does)

5)tcp/ip or udp controll of vncviewer - to tell vncviewer
to skip frames, request refresh, transfer files, change
compression parameters on the fly, and also to gather feedback
from client (debug) - like number of lost frames, congestion
notification, etc

6)time exchange with Xvnc server - to sync displays after 
network congestions.
major problem of VNC is that it uses tcp and not udp to transfer frames, 
and tries to transfer whole screen at once, instead of dividing it before
sending (i.e. 1000x1000 screen would be sent in 10 1000x100 pieces)

this seriously impacts Xvnc when any congestion/packet loss occur,
as it simply can't drop 'old' frames, even in 'more recent' ones
arrive, and display is hardly 'outdated'.