bigbluebutton/bigbluebutton — pull request #81 by rsippl (2012-12-16 12:40:23+00:00)
Title: Deskshare optimizations

Here are some optimizations to the desktop sharing code, we found that they improved real-world performance considerably by reducing traffic and thus the risk of network congestion. Here are our changes:

- reduce the number of sending threads in the applet to 1. In my opinion, using n = 3 * (# of processors) sending threads (as in 0.80) or one thread for each row of blocks (currently in 0.81) doesn't make much sense, data transmission isn't necessarily faster and it results in too many connections

- not sending the block immediately after its content has changed, we hold it back for one more screen sampling interval, then we check again. If it keeps changing, we wait for a limited time for the changes to stop, then we send it. This reduces the risk of congestion considerably. Of course, this also reduces the refresh rate, but we don't intend to share video games or movie playback ;)

- not sending unnecessary mouse location updates; mouse location was sent once per screen sampling, regardless if you moved the mouse or not, which is obviously a waste

- sending a keyframe immediately after joining a session. By default, the first keyframe is sent up to 5 seconds after a viewer joins; I understand that this is done to avoid many keyframes to be sent within a short time (if many viewers are joining simultaneously; that won't be the case for us), but the first subjective impression, while the screen builds up block-wise, is "this is slow!". Fortunately, this behavior could be changed via the deskshare.properties config file (property is called keyFrameInterval; we set it to 0). This pull request does NOT contain any commit that changes this value, but I think that a value of 5000 (5 seconds) is a bit too long and should be reconsidered.