Google Summer of Code 2010/VNC: Difference between revisions

From QEMU
No edit summary
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Summary ==
== Summary ==


QEMU's built-in VNC server only supports the Hextile encoding. Hextile only uses tile-based compression. Other encodings are more popular such as Tight and ZRLE that use zlib-based compression. These encodings significantly reduce the bandwidth required by VNC.  
QEMU's built-in VNC server only supports the Hextile encoding. Hextile only uses tile-based compression. Other encodings are more popular such as Tight and ZRLE that use zlib-based compression. These encodings significantly reduce the bandwidth required by VNC.
 
Another side of the project is to get a threaded vnc server in order to avoid blocking guest while using heavy encodings.


== Owner ==
== Owner ==
Line 178: Line 180:
=== tight ===
=== tight ===


* full color '''work in progress (almost done)'''
'''merged upstream'''
* solid rectangles detections '''work in progress (delayed, need to finished full color first)'''
 
* solid color
Support for tight is complete. JPEG and gradient should be merged soon.
* monochrome
 
* jpeg
=== [[Features/VNC_Tight_PNG|Tight PNG]] ===
* palette filter
 
* gadrient filter
'''merged upstream'''
 
This is a experiment to speed-up noVNC (http://github.com/kanaka/noVNC/ ). This adds a new encoding similar to tight (but without basic/zlib compression): Tight PNG encoding.
 
=== Threaded Encoding Queue ===
 
'''merged upstream'''
 
This project aims to create a queue for encoding computations.
 
If you build qemu with --enable-vnc-thread, the queue will be threaded and (hopefully) send_framebuffer_update() won't block the guest execution anymore.
You will still be able to use a synchroneous queue (current behavior) with --disable-vnc-thread.
 
=== Video Detection and specific encoding ===
 
'''merged upstream'''
 
Adaptive Tight encoding
 
=== ZRLE // ZYWRLE ===
 
'''merged upstream'''

Latest revision as of 07:54, 13 October 2016

Summary

QEMU's built-in VNC server only supports the Hextile encoding. Hextile only uses tile-based compression. Other encodings are more popular such as Tight and ZRLE that use zlib-based compression. These encodings significantly reduce the bandwidth required by VNC.

Another side of the project is to get a threaded vnc server in order to avoid blocking guest while using heavy encodings.

Owner

Detailed Summary

QEMU's built-in VNC server only supports the Hextile encoding. Hextile only uses tile-based compression. Other encodings are more popular such as Tight and ZRLE that use zlib-based compression. These encodings significantly reduce the bandwidth required by VNC. This project would start by implementing support for Tight or ZRLE. Both encodings support a combination of tile-based compression and zlib-compression. Initially, one would implement zlib-compression only and compare the results to our Hextile implementation. Depending on progress, tile-based compression mechanisms (such as Tight's gradient algorithm) could be explored. At each stage, we expect that performance comparisons are done to determine the effectiveness of the additional algorithm. Additional compression mechanisms like Tight's JPEG encoding could also be evaluated.

Encodings

Feature Matrix

Software Raw CopyRect RRE CoRRE Hextile ZRLE ZYWRLE zlib tight zlibhex Ultra UltraZip
libvncclient y y y y y y y y y y y y
libvncserver y y y y y y y y y y y y
tigervnc y y y y? y y n n y n n n
ultravnc y y y y y y y y y y y y
tightvnc y y y y? y y n n y n n n
realvnc
qemu y y n n y n n y n n n n
gtk-vnc y y y n y y n n y n n n


RRE

RRE stands for rise-and-run-length encoding and as its name implies, it is essentially a two-dimensional analogue of run-length encoding. RRE-encoded rectangles arrive at the client in a form which can be rendered immediately and efficiently by the simplest of graphics engines. RRE is not appropriate for complex desktops, but can be useful in some situations.

CoRRE

Note: the CoRRE encoding is almost never useful - Hextile is a better encoding using the same ideas. CoRRE (Compact RRE) is a variant of RRE, where we guarantee that the largest rect- angle sent is no more than 255x255 pixels. A server which wants to send a rectangle larger than this simply splits it up and sends several smaller RFB rectangles.

ZRLE

ZRLE stands for Zlib1 Run-Length Encoding, and combines zlib compression, tiling, palettisation and run-length encoding. On the wire, the rectangle begins with a 4-byte length field, and is followed by that many bytes of zlib-compressed data. A single zlib “stream” object is used for a given RFB protocol connection, so that ZRLE rectangles must be encoded and decoded strictly in order.

Benchmarks

We'll need something to compare different encodings and how much bandwidth/cpu they use. For that we can probably use http://www.lesswatts.org/projects/bltk/ with Idle, Office and Dvd Player workloads.

Status

git tree

tight

merged upstream

Support for tight is complete. JPEG and gradient should be merged soon.

Tight PNG

merged upstream

This is a experiment to speed-up noVNC (http://github.com/kanaka/noVNC/ ). This adds a new encoding similar to tight (but without basic/zlib compression): Tight PNG encoding.

Threaded Encoding Queue

merged upstream

This project aims to create a queue for encoding computations.

If you build qemu with --enable-vnc-thread, the queue will be threaded and (hopefully) send_framebuffer_update() won't block the guest execution anymore. You will still be able to use a synchroneous queue (current behavior) with --disable-vnc-thread.

Video Detection and specific encoding

merged upstream

Adaptive Tight encoding

ZRLE // ZYWRLE

merged upstream