www.cendio.com
Bug 5623 - Performance improvements HTML 5 client (noVNC vendordrop)
: Performance improvements HTML 5 client (noVNC vendordrop)
Status: CLOSED FIXED
: ThinLinc
Web Access
: trunk
: PC Unknown
: P2 Normal
: 4.6.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2015-08-28 11:46 by
Modified: 2016-04-12 12:47 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2015-08-28 11:46:16
There has been substantial performance improvements made to noVNC which we can
benefit from. We should do a new vendordrop.
------- Comment #2 From cendio 2015-11-17 17:00:04 -------
Vendordrop has been done. Nothing seems broken. This has made the requirements
on the browser tighter with the use of Typed Arrays. See:
http://caniuse.com/#feat=typedarrays

Will look into if there is any way we can verify this functionality in the
login-form the same way we check for WebSocket support.
------- Comment #4 From cendio 2015-11-25 15:19:52 -------
Checks have been added for Typed Array support. I have briefly verified this
test on:

Fedora 20 - Chrome 47
Windows XP - IE 8
Windows Vista - IE 9
Windows 7 - IE 11
Windows 10 - Edge 20, Chrome 47
------- Comment #5 From cendio 2015-11-25 15:39:18 -------
Tester should try to verify that the changes brought in from upstream hasn't
broken something. The tests should focus on different graphical operations
since this is where the most of the changes have been made. Due to the amount
of changes I suggest we test recent versions of the browsers on all the
following platforms:

* Internet Explorer (Windows)
* Firefox (Linux, OS X, Windows, Android)
* Google Chrome (Linux, OS X, Windows, Android)
* Safari (OS X, Safari)

The tester should also verify the Typed Array check in a browser which doesn't
support it.
------- Comment #6 From cendio 2015-11-25 15:52:31 -------
Note:

The tests performed by upstream (#487 and #488) measured using
vnc_playback.html how much time took for the browser to play different VNC
recordings. The tests reported a worst-case 10% improvement in performance and
as much as doubled speed in some cases.
------- Comment #7 From cendio 2015-12-03 14:41:35 -------
Running this in the browser's console allows you to disable JPEG:

UI.rfb._encodings.splice(8,1)
RFB.messages.clientEncodings(UI.rfb._sock, UI.rfb._encodings, true, true)

Useful to make sure you get lots of zlib compressed rects.
------- Comment #8 From cendio 2015-12-03 14:52:17 -------
For the old code you had to do this instead:

UI.rfb._sock.send(RFB.messages.clientEncodings(UI.rfb._encodings, true, true))
------- Comment #9 From cendio 2015-12-03 15:18:39 -------
Very promising results for the non-JPEG mode. In a typical portion of active
use you can see:

 - The old code spends 22% of its time decoding zlib and 28% idle.
 - The new code spends 4% of its time decoding zlib and 50% idle.

There is also lots of small frame rate drops in the old code whilst the new
code has no problems keeping up.

There is however a big exception. At a regular interval the GC will kick in and
cause long delays (50-150) ms. This happens consistently every 6-7 seconds. The
old code only has these incidents sporadically.
------- Comment #10 From cendio 2015-12-03 15:38:25 -------
With JPEG on the results are very similar between the new and old code. Most of
the time is spent in "Graphics", which I assume is where Firefox decodes the
JPEG data. 60% is spent there.

The frame rates are similar with both implementations falling slightly short of
keeping up. GC glitches are also common in both cases.

So right now it seems like JPEG is slower than non-JPEG for the HTML client,
oddly enough.
------- Comment #11 From cendio 2015-12-03 16:33:14 -------
I've tested several systems and browsers now and no problems found.

The new test for TypedArray is problematic though. The only browser that has
the weird combination of supporting WebSockets but not TypedArray is Internet
Explorer 10. And we don't have that on any machine and I cannot find a way to
downgrade to it.

A manual inspection of the code shows that it is incorrect anyway though. That
scenario will lead to the UI being enabled when it shouldn't.

So fix it or remove it if we deem it overkill to have this test just because of
IE 10.
------- Comment #14 From cendio 2015-12-04 16:19:15 -------
(In reply to comment #11)
> I've tested several systems and browsers now and no problems found.
> 
> The new test for TypedArray is problematic though. The only browser that has
> the weird combination of supporting WebSockets but not TypedArray is Internet
> Explorer 10. And we don't have that on any machine and I cannot find a way to
> downgrade to it.

The Windows 7 machine in the lab now has IE 10.

> A manual inspection of the code shows that it is incorrect anyway though. That
> scenario will lead to the UI being enabled when it shouldn't.
> 
> So fix it or remove it if we deem it overkill to have this test just because of
> IE 10.

Fixed in revisions 31007 and 31008.
------- Comment #15 From cendio 2015-12-07 14:22:17 -------
(In reply to comment #14)
> (In reply to comment #11)
> > I've tested several systems and browsers now and no problems found.
> > 
> > The new test for TypedArray is problematic though. The only browser that has
> > the weird combination of supporting WebSockets but not TypedArray is Internet
> > Explorer 10. And we don't have that on any machine and I cannot find a way to
> > downgrade to it.
> 
> The Windows 7 machine in the lab now has IE 10.
> 
> > A manual inspection of the code shows that it is incorrect anyway though. That
> > scenario will lead to the UI being enabled when it shouldn't.
> > 
> > So fix it or remove it if we deem it overkill to have this test just because of
> > IE 10.
> 
> Fixed in revisions 31007 and 31008.

Verified using build 4966. Works as expected.