Now working under Arora 0.5.

But not Konqueror 4.2.2 (WebSockets never connects).

IE support with excanvas still pending.

Some default_controls.js jslinting.

Needs to be some modularity between controls you probably always want
(like sending CtrlAltDel) and how the interface is presented and
controlled.

Some basic functions from mootools implemented in util.js.

Also, some more DOM separation. Move clipboard focus logic into
default_controls and canvas and out of vnc.js.

JSLint cleanup.

On path towards removing dependency on mootools in non-UI code.

Also, allow 'include/' to be overridden in VNC_uri_prefix.

- Implement resizing of desktop pseudo-encoding.

- Also send lowest (fastest) compression level pseudo-encoding.
  Ought be user tweakable.

From kevinychan/vnc-html5 ebfffdc36.

Move DOM manipulation into include/default_controls.js and update
vnc.html to use it.

Add an example vnc_auto.html which automatically connects using
parameters from the query string and doesn't use default_controls.js.

Reorder functions in vnc.js to put external interface functions at the
top of the RFB namespace.

In colourMap mode there are 256 colours in a colour palette sent from
the server via the SetColourMapEntries message. This reduces the
bandwidth by about 1/4. However, appearance can be somewhat less than
ideal (pinks instead of gray, etc).

It also increases client side rendering performance especially on
firefox. Rendering a full 800x600 update takes about 950ms in
firefox on my system compared to about 1400ms. Round-trip time for
a full frame buffer update is even better on firefox (due to
performance of the flash WebSocket emulator). Reduced from about
1800ms to 1100ms on firefox (for 800x600 full update).

Also add a wsencoding test client/server program to test send a set of
values between client and server and vice-versa to test encodings.

Not turned on by default.

Add support for encode/decode of UTF-8 in the proxy. This leverages
the browser for decoding the WebSocket stream directly instead of
doing base64 decode in the browser itself.

Unfortunately, in Chrome this has negligible impact (round-trip time
is increased slightly likely due to extra python processing).

In firefox, due to the use of the flash WebSocket emulator the
performance is even worse. This is because it's really annoying to get
the flash WebSocket emulator to properly decode a UTF-8 bytestream.
The problem is that the readUTFBytes and readMultiByte methods of an
ActionScript ByteArray don't treat 0x00 correctly. They return
a string that ends at the first 0x00, but the index into the ByteArray
has been advanced by however much you requested.

This is very silly for two reasons: ActionScript (and Javascript)
strings can contain 0x00 (they are not null terminated) and second,
UTF-8 can legitimately contain 0x00 values. Since UTF-8 is not
constant width there isn't a great way to determine if those methods
in fact did encounter a 0x00 or they just read the number of bytes
requested.

Doing manual decoding using readUTFByte one character at a time slows
things down quite a bit. And to top it all off, those methods don't
support the alternate UTF-8 encoding for 0x00 ("\xc0\x80"). They also
just treat that encoding as the end of string too.

So to get around this, for now I'm encoding zero as 256 ("\xc4\x80")
and then doing mod 256 in Javascript. Still doesn't result in much
benefit in firefox.

But, it's an interesting approach that could use some more exploration
so I'm leaving in the code in both places.

The purpose of the code is to be incorporated into other web projects
(whether those are free or not). AGPL prevents combination with other
HTML and javascript that is under a weaker (or proprietary) license.
Better would be a lesser AGPL, but there is not GNU standard for that.
So LGPL-3 meets most of my requirements. If somebody modifies the
actual client code and conveys it, then they must release the changes
under LGPL-3 also.

Add some implementation notes in docs/notes.

- By dereferencing the 'data' field of the imageData object before the
  loop, the hextile performance on Chrome is down to 140ms or so for
  a full 800x600 update. Still have to fall back to Canvas operations
  for firefox.

- Fix RQ empty after reorder bug.

Pull and modify vnc.css version
b747e284c0e417df1599b1d95724518b07be8df6 to include/black.css

- Other misc cleanups.

- Instead of onload override, move to RFB.load function that takes
  a parameter for the target DOM ID. This allows the user to have
  their own onload function.

- Add "VNC_" prefix to all element ID names. Only create DOM elements
  if they don't already exist on the page, otherwise use the existing
  elements.

- Move all styling to separate stylesheet.

- Use list model for control styling.

On the client side, this adds the as3crypto library to web-socket-js
so that the WebSocket 'wss://' scheme is supported which is WebSocket
over SSL/TLS.

Couple of downsides to the fall-back method:

    - This balloons the size of the web-socket-js object from about 12K to 172K.

    - Getting it working required disabling RFC2718 web proxy support
      in web-socket-js.

    - It makes the web-socket-js fallback even slower with the
      encryption overhead.

The server side (wsproxy.py) uses python SSL support. The proxy
automatically detects the type of incoming connection whether flash
policy request, SSL/TLS handshake ('wss://') or plain socket
('ws://').

Also added a check-box to the web page to enable/disabled 'wss://'
encryption.

as3crypto is actionscript 3 crypto library with TLS engine support.

From: http://github.com/lyokato/as3crypto_patched

Which was forked from: http://code.google.com/p/as3crypto/

- All state/status updates go through updateState routine which
  updates the status line also.

- Old firefox (and opera) don't support canvas createImageData, so use
  getImageData as replacement.

- Add console.warn and console.error stubs so that firefox without
  firebug doesn't crap out.

- If no WebSockets then error if no flash or if URL is location (flash
  will refuse to load the object for security reasons).