Comment 1 Samuel Mannehed 2014-07-02 11:05:18 CEST

This bug includes code review and merging of the upstream work.

Comment 2 Samuel Mannehed 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 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 2014-09-16 11:16:16 CEST

https://github.com/kanaka/noVNC/pull/368 is now merged upstream

Comment 5 Samuel Mannehed 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 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 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 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.