Of interest to folks on this list.. I've just noticed work on qemu-devel proposing a new variant of the Tight framebuffer encoding that uses PNG for compression instead of JPEG:
http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg00445.html "Tight PNG ========== This set introduce a new encoding: VNC_ENCODING_TIGHT_PNG [1] (-260) and a new tight filter VNC_TIGHT_PNG (0x0A). When the client tells it supports the -260 encoding, the server will use tight, but will always send encoding pixels using PNG instead of zlib. If the client also told it support JPEG, then the server can send JPEG, because PNG will only be used in the cases zlib was used in normal tight. This encoding was introduced to speed up HTML5 based VNC clients like noVNC but can also be used on devices like iPhone where PNG can be rendered in hardware." I know the encoding -260 has already been allocated for use by QEMU, but I'm not sure who is maintaining the authority for tight filter numbers & can thus records/approves the use of 0x0a ? Is the latter something we should be doing here if no one else is an authority for tight filters ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
