There has been substantial performance improvements made to noVNC which we can benefit from. We should do a new vendordrop.
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.
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
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.
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.
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.
For the old code you had to do this instead: UI.rfb._sock.send(RFB.messages.clientEncodings(UI.rfb._encodings, true, true))
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.
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.
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.
(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.
(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.
