From 4ab1998aac675353584c99ddef01ccc906b15bfe Mon Sep 17 00:00:00 2001 From: Joel Martin Date: Mon, 21 Mar 2011 16:34:12 -0500 Subject: [PATCH] Update firefox 4.0 support. Misc perf notes updates. --- Browser-support.md | 4 ++-- Performance-notes.md | 10 +++++++--- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/Browser-support.md b/Browser-support.md index a0d7968..6a6fb36 100644 --- a/Browser-support.md +++ b/Browser-support.md @@ -20,9 +20,9 @@ This list show results of testing noVNC on various browser and OS combinations. Excellent Very fast. Native WebSockets. - Firefox 4.0 Beta 9 + Firefox 4.0 Good - Native WebSockets must be turned on (see note 4) + Very good with native WebSockets enabled (see note 4) Firefox 4.0 Beta 6 Excellent diff --git a/Performance-notes.md b/Performance-notes.md index ebb8f01..1eed9e7 100644 --- a/Performance-notes.md +++ b/Performance-notes.md @@ -76,10 +76,14 @@ direction to go in this area. ### tight encoding +Of the normal RFB encodings noVNC supports "raw", "copyrect", "RRE" +and "hextile". The "hextile" encoding is much more bandwidth efficient +than "raw" or "RRE" but it is still not nearly as efficient as some of +the other zlib based encodings: "zlib", "ZRLE", and "tight". + I briefly explored implementing the "tight" encoding in noVNC but -quickly discovered that tight uses zlib to compress the lossless pixel -data in the stream. Decompressing zlib in Javascript is relatively -slow so I gave up on that route. +tight uses zlib compression and decompressing zlib directly in +Javascript is relatively slow so I gave up on that route. However, there might be a way to trick the browser into doing zlib decompression in native code instead of Javascript. Tobias Schneider