vncserv 0.11
Copyright (C) Adrian Lees 2010

This is an alpha-quality prototype release of a VNC server for RISC OS machines. It is NOT reliable or efficient and should be regarded only as an amusement or a demonstration of what is possible in any putative future version. I'm releasing it only because I think it's at a point where it can be used, at least to some extent, and because this project is something that I started years ago and it may yet languish further.


Instructions
------------

Frankly, if you're not familiar with VNC at all, you probably shouldn't be attempting to use this server as it stands, but to start it you need only double-click the module to load it, and know the IP address of the machine that you're running it on. Then, in your VNC client, enter the machine's address and it should respond as display 0 (equivalent to port 5900). By default the server will not demand password authentication, though if you start the module from the command line with:

  vncserv [-password <password>][-display <n>][-port <port>][-timeout <timeout in seconds>]

some or all of the options may work ;) It's been a long time since I wrote/tested that code.


Weaknesses
----------

It is actively being improved at the time of writing, March 2010, after being neglected for many years, but still has many obvious problems:

 - very inefficient memory usage (28MB dynamic area created on startup, it will not work on low-memory machines)
 - copy/fill rect accelerations (when running on the IYONIX pc) are not properly sequenced with screen updates,
   leading to screen corruptions on the VNC client)
 - no proper handling of 256-colour modes. You may get an usable picture, you may not.
 - both the keyboard handling and the mouse click handling have no proper concept of time, so double-clicking is apt to be difficult (being deliberately slower than usual with the second click is more likely to work), and when pressing keys you may well get 0 or 2 responses to the key, where 1 was intended.
 - there's no detection of screen updates as they occur, so the server reads back from the screen to detect changes. This is very slow and inefficient, especially on the IYONIX pc. To mitigate the delay, you will (if it works at all for you!) notice that it employs a 'rolling shutter' approach, meaning that screen refreshes on the client take a long time.

Possible future development
---------------------------

The plan has always been to employ code similar to that used in Geminus (the acceleration/multi-monitor software for the IYONIX pc) to intercept screen accesses as they occur and thus provide far more efficient descriptions of screen updates to the VNC client), and to trap and accelerate rectangle copy/fill and sprite plotting operations. The current prototype contains only functional code for describing screen updates using the VNC protocol and does not attempt to so efficiently. On the IYONIX pc it does provide increased responsiveness on the client by describing rectangle copies and fills (ie. moving, scrolling and opening windows will generally be faster), making it IMHO somewhat better already than the earlier RISC OS VNC servers I've encountered, but it is still a poor approximation to what is possible.

If you're interested in seeing this developed further too, feel free to report any problems not described above, including details of the VNC client(s) you've tried with it, and the machine/OS version you're running it on. Or feature requests etc. It may decrease the odds of me losing interest again ;) In the meantime, I hope it amuses you, or - reaching somewhat - may even be useful.


Adrian
adrian@aemulor.com
