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.
         <td>Excellent</td>
         <td>Very fast. Native WebSockets.</td>
     </tr> <tr>
-        <td>Firefox 4.0 Beta 9</td>
+        <td>Firefox 4.0</td>
         <td>Good</td>
-        <td>Native WebSockets must be turned on (see note 4)</td>
+        <td>Very good with native WebSockets enabled (see note 4)</td>
     </tr> <tr>
         <td>Firefox 4.0 Beta 6</td>
         <td>Excellent</td>
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