Generally, most servers send hextile updates as single updates
containing many rects. Some servers send hextile updates as many small
framebuffer updates with a few rects each (such as QEMU). This latter
cases revealed that shifting off the beginning of the receive queue
(which happens after each hextile FBU) performs poorly.
This change switches to using an indexed receive queue (instead of
actually shifting off the array). When the receive queue has grown to
a certain size, then it is compacted all at once.
The code is not as clean, but this change results in more than 2X
speedup under Chrome for the pessimal case and 10-20% in firefox.
Apparently there are versions of UltraVNC that report version 3.6.
This is not a legal version according to the spec, but we'll just
force version 3.3 if we receive it. Thanks to Larry Rowe for the info.
Turns out when Windows is running in QEMU and a window scroll happens,
there are lots of little hextile rects sent. This is slow in noVNC.
- Some recording/playback improvement.
- Add test harness to drive playback of recordings.
- By pulling off the rect header in one chunk we get a 3X speedup in
Chrome and a 20% speedup in firefox (specifically for the scroll
test).
- Also, get rid of some noise from creating timers for handle_message.
Check to make sure there isn't already a pending timer first.
This is very usefull when you need to open a new window (with a new document) from javascript,
without having to reload the script.js.
(cherry picked from commit 8ded53c1de06d01e50d58543c19e73926f0fbbd4)
Signed-off-by: Joel Martin <github@martintribe.org>
New API:
To use the RFB object, you now must instantiate it (this allows more
than one instance of it on the same page).
rfb = new RFB(settings);
The 'settings' variable is a namespace that contains initial default
settings. These can also be set and read using 'rfb.set_FOO()' and
'rfb.get_FOO()' where FOO is the setting name. The current settings
are (and defaults) are:
- target: the DOM Canvas element to use ('VNC_canvas').
- encrypt: whether to encrypt the connection (false)
- true_color: true_color or palette (true)
- b64encode: base64 encode the WebSockets data (true)
- local_cursor: use local cursor rendering (true if supported)
- connectTimeout: milliseconds to wait for connect (2000)
- updateState: callback when RFB state changes (none)
- clipboardReceive: callback when clipboard data received (none)
The parameters to the updateState callback have also changed. The
function spec is now updateState(rfb, state, oldstate, msg):
- rfb: the RFB object that this state change is for.
- state: the new state
- oldstate: the previous state
- msg: a message associate with the state (not always set).
The clipboardReceive spec is clipboardReceive(rfb, text):
- rfb: the RFB object that this text is from.
- text: the clipboard text received.
Changes:
- The RFB and Canvas namespaces are now more proper objects. Private
implementation is no longer exposed and the public API has been made
explicit. Also, instantiation allows more than one VNC connection
on the same page (to complete this, DefaultControls will also need
this same refactoring).
- Added 'none' logging level.
- Removed automatic stylesheet selection workaround in util.js and
move it to defaultcontrols so that it doesn't interfere with
intergration.
- Also, some major JSLinting.
- Fix input, canvas, and cursor tests to work with new model.
After each complete framebufferUpdate, set a short timer to continue
processing the receive queue. This gives other events a chance to
fire. Especially important when noVNC is integrated into another
website.
noVNC was never processing more than one framebufferUpdate message per
onmessage event. If noVNC receives an incomplete framebufferUpdate and
then receives the rest of the framebufferUpdate plus another complete
framebufferUpdate, then it will fall permanently behind.
If there is more to process after a completed framebufferUpdate, then
execute normal_msg again.
All the render routines must return false if there is not enough data
in the receive queue to process their current update, and true
otherwise.
Move the whole RFB object to rfb.js. vnc.js is now just the loader
file. This allows an integrating project to easily replace vnc.js with
an alternate loader mechanism (or just do it directly in the html
file). Thanks for the idea primalmotion (http://github.com/primalmotion).
Also, JSLint the various files.
Joel Martin
primalmotion