Previously, we used a fixed chunkSize of 100KiB for Pako's output
buffer. Using a hardcoded size caused issues, since Pako would assume
we wanted to use multiple chunks, and we didn't deal with this. Now,
`Inflator#inflate()` takes a new `expected` argument, which indicates
the expected output size. If this is bigger than the current chunkSize,
Inflator allocates a new output buffer that's big enough to hold the
output.
Fixes#531
For performance reasons, the `handle_tight` function skips the
use of the receive queue API and uses the raw receive queue directly.
Because of the way that typed array receive queue gets reused, this
introduced the potential for buffer over-reads.
To address this, a new function, `rQwhole`, was introduced.
`rQwhole` simply returns a new view into the receive queue that
starts at 0 and ends at the current recorded end of the queue.
`handle_tight` now makes use of this function.
Fixes#522
This commit skips object creation for the render queue when not
needed. Instead of pushing an object onto the queue, and then
immediately running the result, you call the function directly.
Then, if the render queue is not empty, an object is created and
pushed onto the queue. Otherwise, the functionality is just run
directly.
This commit converts the send queue to use typed arrays, and converts
message creation functions in 'rfb.js' to create messages directly into
the socket's send queue. This commit also removes the separate mouse array,
which is no longer needed.
Creating lots of small objects frequently can drastically decrease
performance. This commit introduces three fixes which avoid this:
- Use a preallocated palette and indexed-to-rgb destination Typed Array
(the destination typed array is currently allocated at `4 * width *
height`).
- Inline `getTightCLength`, which returned a two-item array.
- Pass RGBX data directly in a Typed Array to the Display, which
avoids an extra loop, and only creates a new Typed Array View,
instead of a whole new ArrayBuffer.
**This commit removes Base64 (and Flash) support**
This commit converts websock.js to used Typed Arrays for the
receive queue (and tweaks rfb.js to ensure that it continues
to function, since only Firefox implements
`%TypedArray%.prototype.slice`). Base64 support was removed
to simplify code paths, and pave the way for using Typed Arrays
for the send queue as well.
This provides two advantages: first, we allocate a buffer ahead
of time, meaning the browser doesn't have to do any work dynamically
increasing the receive queue size. Secondly, we are now able to pass
around Typed Array Views (e.g. `Uint8Array`), which are lightweight, and
don't involve copying.
The downside is that we initially allocate more memory -- we currently
start out with 4 MiB, and then automatically double when it looks like
the amount unused is getting to small.
The commit also explicitly adds a check to the compacting logic that
avoids calling the copy functions if `_rQlen === _rQi`.
Previously, if an error was thrown from the Display constructor
in the RFB constructor, we would attempt to use `RFB#updateState`
to handle this. However, `RFB#updateState` attempts to close
the WebSocket connection, which doesn't exist at this point.
In the constructor, it's probably just better to raise an exception
instead (making sure to clean up anything relevant).
Fixes#460
* Added better error handling in ExtendedDesktopSize
* Added helper function to share code with DesktopSize
* Update test.rfb.js to only check for error handling if we were the
ones requesting the resize
Commit 155d78b399 prevented reconnections
from working properly. This fixes that by creating a new RFB object
after disconnecting or failing.
Furthermore, this ensures that a new connection cannot be opened util
we've actually disconnected (either by timer or by receiving a `close`
event).
Closes#452
Previously, if a HEXTILE tiles was received with a subencoding
of 0x00, it would draw a rectangle using data from the render
queue, which would result in random colored blocks when using
the HEXTILE encoding. This is the result of a miscopy during
the refactoring. It now has the correct functionality according
to the RFB protocol specification, which is to draw a rectangle
with the last set background color.
Closes#411
There was a typo in one of the instances of the _buttonMask field
(it was written as _buttonMaks), causing MouseUp to never be sent.
This has been rectified, and the unit tests for the mouse handler
have been changed to check for explicitly sending mouseup and
mousedown.
Fixes#393
This allows the keyboard handler to check modifier key state much more frequently
Since some browsers never send keyup events for modifier keys, we have to
synchronize modifier state whenever we get a mouse or keyboard event
FBU.bytes must be set before return false to indicate that the FBU
header has been read. If not set then "if (FBU.bytes == 0) { ..}"
in framebufferUpdate will be entered and the copyrect header will
be interpreted as a new FBU leading to a "unsupported encoding"
disconnect error.
Related to issue/pulls:
https://github.com/kanaka/noVNC/issues/194https://github.com/kanaka/noVNC/pull/201https://github.com/kanaka/noVNC/pull/202
In IE9, the window.onload event can fire before dynamically loaded
scripts have finished loading. This can result in either WebSocket (in
the case of vnc_auto.html) or RFB (in the case of vnc.html) not being
defined at the point when window.onload is called.
- Move the load_scripts routine from vnc.js to util.js (so that
websockify can use it too). Also, refactor to work when load_scripts
is called by a script that itself uses load_scripts. When the whole
chain of dynamically loaded scripts is finished then call
window.onscriptsload. Use this mechanism in all the places that
depend on dynamic loading of scripts: vnc.html, vnc_auto.html,
websock.js, tests/vnc_playback.html, and tests/vnc_perf.html.
- Use the new window.onscriptsload handler instead of window.onload.
- Remove include/start.js and do the script loading and startup event
handling in include/ui.js instead.
The MPL 2.0 license is a "file-level" copyleft license vs the
"project-level" nature of the L/GPL. The intention of noVNC has
always been that it should be easy to incorporate into existing
projects and sites whether free/open or proprietary/commercial. The MPL
2.0 is designed for this sort of combination project but still
requires that any distributed modifications to noVNC source files must
also be published under the same license.
In addition, the MPL 2.0 allows the code to be used in L/GPL projects
(the secondary license clause). This means that any projects that are
already incorporating noVNC should not be impacted by this change and
in fact it should clarify the licensing situation (the exact
application of the L/GPL to web applications and interpreted code is
somewhat ambiguous).
The HTML, CSS, image and font files continue to be under more
permissive licenses (see LICENSE.txt). The included websockify python
code remains under a LGPLv3 license although the include/websock.js
file from the websockify component is now under MPL 2.0 as well.
Permission was received from other noVNC authors to make this change to their
code license on the following dates:
- Chris Gordon (UI): Jun 24, 2012
- Antoine Mercadal (DOM,*util.js): Oct 10, 2012
- William Lightning (UltraVNC repeater): Oct 10, 2012
- Mike Tinglof (tight encoding): Oct 15, 2012
Use a simpler method of enabling binary transfer over WebSockets. This
still presents the user of websock.js with a plain javascript array
for the receive queue data. However, if binary support is supported
and requested then the transfer will be raw frames instead of base64
encoded.
Lots of room for optimization here but for now correct is better than
fast.
Pull from websockify 17175afd7311c55abd8d
Solly Ross
samhed
Solly
Jacob Swanner
Joe Huss
Ramon de Klein
Julien Fontanet
Solly
Dominic Luechinger
Malcolm Scott
Brian Rak
jalf
Anton Lundin
Joel Martin
Vagn Johansen