Bug 5178 - Do a new vendordrop of noVNC
Summary: Do a new vendordrop of noVNC
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Target Milestone: 4.4.0
Assignee: Samuel Mannehed
Keywords: ossman_tester, prosaic
Depends on:
Reported: 2014-06-03 10:49 CEST by Samuel Mannehed
Modified: 2015-04-30 14:15 CEST (History)
0 users

See Also:
Acceptance Criteria:

CPU usage comparison before and after the refactor, Chrome CPU profile samples (260.00 KB, application/gzip)
2014-11-24 15:25 CET, Samuel Mannehed

Description Samuel Mannehed cendio 2014-06-03 10:49:45 CEST
noVNC is in the thick of some cleanup and restructuring, partly in this pullrequest: https://github.com/kanaka/noVNC/pull/368

We should stay as close to upstream as possible and should therefore do a new vendordrop.
Comment 1 Samuel Mannehed cendio 2014-07-02 11:05:18 CEST
This bug includes code review and merging of the upstream work.
Comment 2 Samuel Mannehed cendio 2014-07-04 14:36:04 CEST
I've reviewed all of the upstream code. Once the changes are merged upstream I will do a vendor drop and solve the merge to our tree.
Comment 3 Samuel Mannehed cendio 2014-09-10 14:29:19 CEST
We decided to move this to 4.4 since upstream didn't merge in time.
Comment 4 Samuel Mannehed cendio 2014-09-16 11:16:16 CEST
https://github.com/kanaka/noVNC/pull/368 is now merged upstream
Comment 5 Samuel Mannehed cendio 2014-11-13 13:36:24 CET
Preparatory commits to minimize diffs to upstream: 29589, 29592, 29594

Vendordrop finished in r29596.

Due to the substantial rewrites upstream all of the ThinLinc specific code found in noVNC had to be refactored and reworked. As a part of this work I've modified our code to make the ThinLinc specific parts easier to distinguish in order to make future vendordrops easier.
Comment 6 Samuel Mannehed cendio 2014-11-24 15:22:43 CET
I've done a few quick and unscientific tests using the CPU profiler in Chrome. I played a 10 second video in the session and compared the CPU usage by the HTML5 client before and after these changes. The sample time was 10 seconds.

The result was an average of 9% improvement in processing speed in the JavaScipt code. However, it's very important to note here that, out of the 10 samples, big improvements were only seen in 3 . In the remaining 7 samples the differences between before and after were below 1%.

At the moment I don't have any explanations to why improvements only could be seen in in 3 out of the 10 samples. However, I draw the conclusion that the changes brought in from upstream are at least not lowering the performance.. Good enough for me.
Comment 7 Samuel Mannehed cendio 2014-11-24 15:25:32 CET
Created attachment 591 [details]
CPU usage comparison before and after the refactor, Chrome CPU profile samples
Comment 8 Pierre Ossman cendio 2015-04-30 14:15:19 CEST
Difficult to do any exact measurements here. But Firefox profiler seems to indicate that it is keeping up with the data properly at least, and Firefox is not consuming massive amounts of CPU. There are some glitches when the garbage collector hits, but its not a big problem.

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