Support in tightPNG for non-truecolor (palette/colour mapped)

[kanaka]

The tightPNG support in libvncserver was ported from support in QEMU/KVM.

Here is the original change that added tightPNG support to libvncserver. https://github.com/kanaka/libvncserver/commit/503289ae0d164e7c47fa58dabedb610f3d532d65

The main change that added tightPNG support to QEMU/KVM is efe556adb75a20ab71f3e5b1c5b19bf045e7953f

The web interface to QEMU git is down at the moment. Here is a copy: https://gitorious.org/vm-gl-accel/qemu-gl/commit/efe556adb75a20ab71f3e5b1c5b19bf045e7953f

Or you can just clone the qemu repo from: git://git.qemu.org/qemu.git

The starting point is really in SendPngRect() and comparing it to the similar function send_png_rect() in QEMU/KVM.

To build libvncserver:

./configure --with-x11vnc
make

Run a simple test program:

./example/blooptest

Then launch noVNC and connect directly to port 5900 on the system where you are running blooptest (no websockify necessary). This will work with "True Color" enabled in the settings menu. If you disable true color, you will get an error because libvncserver's tightPNG colour map/palette code for tightPNG is incomplete and not sending all the necessary data.

If you build qemu with --enable-vnc-png (tightPNG), then you will have a tightPNG example that works with both truecolor and non-truecolor. Note with QEMU you will need to use websockify to proxy/bridge since qemu does not have builtin WebSocket support (not yet anyway ;-) ).

[kanaka]

I take that back. While qemu has palette handling code that is not ported to libvncserver, it doesn't actually support non-true_color mode. The palette handling code in send_png_rect() should form pretty good starting basis for the non-true_color mode in libvncserver however.

[dscho]

Please note that @kanaka is not a maintainer of LibVNCServer I just added an official GitHub repository for the project: https://github.com/LibVNC/libvncserver. Please consider opening the pull request there.