moving from Compression Level (CL) 5 to CL 9 in the TightVNC
encoder did not increase the compression ratio of any datasets more
than 10%, and the compression ratio only increased by more than 5%
on four of them. The compression ratio actually decreased a few
percent on five of them. In exchange for this paltry increase in
compression ratio, the CPU usage, on average, went up by a factor of
5. Thus, for all intents and purposes, TightVNC CL 5 provides the
"best useful compression" for that encoder. -- TurboVNC's best compression level (CL 2) compresses 3D and video
workloads significantly more "tightly" than TightVNC CL 5 (~70%
better, in the aggregate) but does not quite achieve the same level
of compression with 2D workloads (~20% worse, in the aggregate.)
This decrease in compression ratio may or may not be noticeable,
since many of the datasets it affects are not performance-critical
(such as the console output of a compilation, etc.) However, for
peace of mind, it was still desirable to have a mode that compressed
with equal "tightness" to TightVNC CL 5, since we proposed to
replace that encoder entirely. -- A new mode was discovered in the TurboVNC encoder that produces,
in the aggregate, similar compression ratios on 2D datasets as
TightVNC CL 5. That new mode involves using Zlib level 7 (the same
level used by TightVNC CL 5) but setting the "palette threshold" to
256, so that indexed color encoding is used whenever possible. This
mode reduces bandwidth only marginally (typically 10-20%) relative
to TurboVNC CL 2 on low-color workloads, in exchange for nearly
doubling CPU usage, and it does not benefit high-color workloads at
all (since those are usually encoded with JPEG.) However, it
provides a means of reproducing the same "tightness" as the TightVNC encoder on 2D workloads without sacrificing any compression for
3D/video workloads, and without using any more CPU time than
necessary. -- The TurboVNC encoder still performs as well or better than the
TightVNC encoder when plain libjpeg is used instead of
libjpeg-turbo. Specific notes follow: common/turbojpeg.c common/turbojpeg.h: Added code to emulate the
libjpeg-turbo colorspace extensions, so that the TurboJPEG wrapper
can be used with plain libjpeg as well. This required updating the
TurboJPEG wrapper to the latest code from libjpeg-turbo 1.2.0,
mainly because the TurboJPEG 1.2 API handles pixel formats in a much
cleaner way, which made the conversion code easier to write. It
also eases the maintenance to have the wrapper synced as much as
possible with the upstream code base (so I can merge any relevant
bug fixes that are discovered upstream.) The libvncserver version of
the TurboJPEG wrapper is a "lite" version, containing only the JPEG
compression/decompression code and not the lossless transform, YUV
encoding/decoding, and dynamic buffer allocation features from
TurboJPEG 1.2. configure.ac: Removed the --with-turbovnc option. configure still
checks for the presence of libjpeg-turbo, but only for the purposes
of printing a performance warning if it isn't available. rfb/rfb.h: Fix a bug introduced with the initial TurboVNC encoder
patch. We cannot use tightQualityLevel for the TurboVNC 1-100
quality level, because tightQualityLevel is also used by ZRLE.
Thus, a new parameter (turboQualityLevel) was created. rfb/rfbproto.h: Remove TurboVNC-specific #ifdefs and language libvncserver/rfbserver.c: Remove TurboVNC-specific #ifdefs. Fix
afore-mentioned tightQualityLevel bug. libvncserver/tight.c: Replaced the TightVNC encoder with the
TurboVNC encoder. Relative to the initial TurboVNC encoder patch,
this patch also: -- Adds TightPng support to the TurboVNC encoder --
Adds the afore-mentioned low-bandwidth mode, which is mapped
externally to Compression Level 9 test/*: Included TJUnitTest (a regression test for the TurboJPEG
wrapper) as well as TJBench (a benchmark for same.) These are
useful for ensuring that the wrapper still functions correctly and
performantly if it needs to be modified for whatever reason. Both
of these programs are derived from libjpeg-turbo 1.2.0. As with the
TurboJPEG wrapper, they do not contain the more advanced features of
TurboJPEG 1.2, such as YUV encoding/decoding and lossless
transforms.
2012-03-15 Christian Beier <dontmind@freeshell.org>
* AUTHORS: Add DRC to AUTHORS.
2012-03-15 Christian Beier <dontmind@freeshell.org>
* rfb/rfb.h: Move tightsubsamplevel member to the end of rfbClient
struct. Try to not break ABI between releases. Even if the code gets ugly...
2012-03-10 DRC <information@virtualgl.org>
* x11vnc/Makefile.am: Fix the build of x11vnc when an out-of-tree
build directory is used
2012-03-10 DRC <information@virtualgl.org>
* libvncserver/rfbserver.c: Fix an issue that affects the existing
Tight encoder as well as the newly-implemented Turbo encoder. The issue is that, when using the current libvncserver source, it is
impossible to disable Tight JPEG encoding. The way Tight/Turbo
viewers disable JPEG encoding is by simply not sending the Tight
quality value, causing the server to use the default value of -1.
Thus, cl->tightQualityLevel has to be set to -1 prior to processing
the encodings message for this mechanism to work. Similarly, it is
not guaranteed that the compress level will be set in the encodings
message, so it is set to a default value prior to processing the
* CMakeLists.txt: cmake: adapted to latest websocket crypto changes
2011-12-15 Christian Beier <dontmind@freeshell.org>
* rfb/rfbclient.h: Small changes to LibNVCClient doxygen
documentation.
2011-12-01 Christian Beier <dontmind@freeshell.org>
* libvncserver/Makefile.am: Fix build error when libpng is
available, but libjpeg is not. The png stuff in tight.c depends on code in tight.c that uses
libjpeg features. We could probably seperate that, but for now the
dependency for 'tight' goes: PNG depends on JPEG depends on ZLIB. This is reflected in Makefile.am now. NB: Building tight.c with JPEG but without PNG is still possible, but nor the other way around.
2011-12-01 Christian Beier <dontmind@freeshell.org>
* configure.ac: Use AM_SILENT_RULES only when it's actually
available. Otherwise building breaks with older make versions. Happens on OS X
10.6 for instance.
2011-11-09 Christian Beier <dontmind@freeshell.org>
2011-11-09 Christian Beier <dontmind@freeshell.org>
* classes/index.vnc, libvncserver/httpd.c: novnc client: use the
client's notion about the server hostname instead of what the server
thinks.
2011-11-09 Christian Beier <dontmind@freeshell.org>
* classes/index.vnc: Fix tiny typo.
2011-11-09 Christian Beier <dontmind@freeshell.org>
* NEWS: Add 0.9.8.2 NEWS entry.
2011-11-09 Christian Beier <dontmind@freeshell.org>
* libvncclient/rfbproto.c: When GetCredential() callback is not set,
don't use authentications requiring it. The auth methods that employ Getcredential() will only be used if
the client's GetCredential callback is actually set.
2011-10-12 Christian Beier <dontmind@freeshell.org>
* ChangeLog: Update ChangeLog for 0.9.8.1.
2011-10-12 Christian Beier <dontmind@freeshell.org>
2011-10-12 Christian Beier <dontmind@freeshell.org>
* CMakeLists.txt, NEWS, configure.ac: Update version number in
* CMakeLists.txt, NEWS, configure.ac: Update version number in
autotools && cmake, NEWS entry.
autotools && cmake, NEWS entry.
2011-10-26 Peter Watkins <watkipet@gmail.com>
* rfb/rfbclient.h: Added comments.
2011-10-26 Christian Beier <dontmind@freeshell.org>
* libvncserver/rfbserver.c: Fix deadlock in threaded mode when using
nested rfbClientIteratorNext() calls. Lengthy explanation follows... First, the scenario before this patch: We have three clients 1,2,3 connected. The main thread loops through
them using rfbClientIteratorNext() (loop L1) and is currently at
client 2 i.e. client 2's cl_2->refCount is 1. At this point we need
to loop again through the clients, with cl_2->refCount == 1, i.e. do
a loop L2 nested within loop L1. BUT: Now client 2 disconnects, it's clientInput thread terminates
its clientOutput thread and calls rfbClientConnectionGone(). This
LOCKs clientListMutex and WAITs for cl_2->refCount to become 0. This
means this thread waits for the main thread to release cl_2.
Waiting, with clientListMutex LOCKed! Meanwhile, the main thread is about to begin the inner
rfbClientIteratorNext() loop L2. The first call to
rfbClientIteratorNext() LOCKs clientListMutex. BAAM. This mutex is
locked by cl2's clientInput thread and is only released when
cl_2->refCount becomes 0. The main thread would decrement
cl_2->refCount when it would continue with loop L1. But it's waiting
for cl2's clientInput thread to release clientListMutex. Which never
happens since this one's waiting for the main thread to decrement
cl_2->refCount. DEADLOCK. Now, situation with this patch: Same as above, but when client 2 disconnects it's clientInput thread
rfbClientConnectionGone(). This again LOCKs clientListMutex, removes
cl_2 from the linked list and UNLOCKS clientListMutex. The WAIT for
cl_2->refCount to become 0 is _after_ that. Waiting, with
clientListMutex UNLOCKed! Therefore, the main thread can continue, do the inner loop L2 (now
only looping through 1,3 - 2 was removed from the linked list) and
continue with loop L1, finally decrementing cl_2->refCount, allowing
cl2's clientInput thread to continue and terminate. The resources
held by cl2 are not free()'d by rfbClientConnectionGone until
cl2->refCount becomes 0, i.e. loop L1 has released cl2.
2011-10-16 Johannes Schindelin <johannes.schindelin@gmx.de>
* AUTHORS: Update AUTHORS Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2011-10-16 George Fleury <gfleury@gmail.com>
* libvncserver/rfbserver.c: Fix memory leak I was debbuging some code tonight and i found a pointer that is not
been freed, so i think there is maybe a memory leak, so it is... there is the malloc caller reverse order: ( malloc cl->statEncList ) <- rfbStatLookupEncoding <- rfbStatRecordEncodingSent <- rfbSendCursorPos <- rfbSendFramebufferUpdate <- rfbProcessEvents I didnt look the whole libvncserver api, but i am using
rfbReverseConnection with rfbProcessEvents, and then when the client
connection dies, i am calling a rfbShutdownServer and
rfbScreenCleanup, but the malloc at rfbStatLookupEncoding isnt been
freed. So to free the stats i added a rfbResetStats(cl) after
rfbPrintStats(cl) at rfbClientConnectionGone in rfbserver.c before
free the cl pointer. (at rfbserver.c line 555). And this, obviously,
is correcting the memory leak. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2011-10-08 Johannes Schindelin <johannes.schindelin@gmx.de>
2011-10-08 Johannes Schindelin <johannes.schindelin@gmx.de>
* rfb/rfbclient.h: Hopefully fix the crash when updating from 0.9.7
* rfb/rfbclient.h: Hopefully fix the crash when updating from 0.9.7
...
@@ -12,6 +706,382 @@
...
@@ -12,6 +706,382 @@
therefore guaranteed to have the correct size) and still rely on the
therefore guaranteed to have the correct size) and still rely on the
same position of the parts the callers know about. Reported by Luca Falavigna. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
same position of the parts the callers know about. Reported by Luca Falavigna. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2011-10-09 Johannes Schindelin <johannes.schindelin@gmx.de>
* client_examples/SDLvncviewer.c: SDLvncviewer: make it resizable by
default I got annoyed having to specify -resizable all the time; I never use
it in another mode anymore, since I am on a netbook. The option -no-resizable was added to be able to switch off that
feature. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2011-10-06 Christian Beier <dontmind@freeshell.org>
* libvncserver/httpd.c: httpd: fix sending of binary data such as
images. We do this simply by omitting the content-type and let the browser
decide upon the mime-type of the sent file. Only exception is
'index.vnc', where we do set the content-type since some browsers
fail to detect it's html when it's ending in '.vnc' Also, remove superfluous #defines. We close the connection always.
2011-10-06 Christian Beier <dontmind@freeshell.org>
* classes/index.vnc: Fix typo && use proper website.
2011-10-04 Christian Beier <dontmind@freeshell.org>
Signed-off-by: Christian Beier <dontmind@freeshell.org>
2011-04-30 Christian Beier <dontmind@freeshell.org>
* libvncserver/tight.c: Revert "Fix memory corruption bug." This reverts commit c1363fa9583ed41b94fbc79b3ff410b7d5189407. The proper fix was already in
804335f9d296440bb708ca844f5d89b58b50b0c6.
2011-04-28 Johannes Schindelin <johannes.schindelin@gmx.de>
* AUTHORS: UTF-8ify AUTHORS Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2011-04-28 Johannes Schindelin <johannes.schindelin@gmx.de>
* AUTHORS: Update AUTHORS Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2010-11-10 George Kiagiadakis <kiagiadakis.george@gmail.com>
* libvncserver/tight.c: Fix memory corruption bug. This bug occured when a second telepathy tubes client was connected
after the first one had disconnected and the channel (thus, the
screen too) had been destroyed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2010-11-10 George Kiagiadakis <kiagiadakis.george@gmail.com>
* common/zywrletemplate.c, libvncserver/auth.c,
libvncserver/rfbserver.c, libvncserver/scale.c,
libvncserver/scale.h, rfb/rfb.h: Fix compilation in c89 mode. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
