faster damage processing - bandwidth constraints handling

[totaam]

Follow up from #999. These classes are becoming complicated and slow.

TODO:

• run profiling again
• merge video source? (we never use window source on its own anyway)
• support multiple video regions?
• cythonize, use strongly typed and faster "deque":Ring buffers in Python/Numpy
• pre-calculate more values: ECU "engine map" like
• more gradual refresh when under bandwidth constraints and at low quality: the jump from lossy to lossless can use up too much bandwidth, maybe refresh first at 80% before doing true lossless
• use more bandwidth? (macos client could use more quality?)
• slowly updating windows should be penalized less
• don't queue more frames for encoding after a congestion event (ok already?)
• maybe keep track of the refresh compressed size?

See also #920: some things could be made faster on the GPU..

[totaam]

See also #1761

[totaam]

See also #1769 comment:1 : maybe we should round up all screen updates to ensure we can always use color subsampling and video encoders? Or only past a certain size to limit the cost?

[totaam]

2018-03-08 17:59:55: antoine uploaded file encoding-selection.png (236.2 KiB)

profiling encoding selection

[totaam]

After much profiling, it turns out that encoding selection is actually pretty fast already (see above).
And so we're better off spending extra time choosing the correct encoding, instead of trying to save time there: r18669.
Other micro improvements: r18667, r18668

See also #1299#comment:6, we seem to be processing the damage events fast enough (~0.25ms for do_damage), but maybe we're scheduling things too slowly when we get those damage storms?

[totaam]

For the record, I've used this command to generate the call graphs:

python2 ./tests/scripts/pycallgraph -i damage -- start --start-child="xterm -ls" --no-daemon

Minor related fix: r18685.

Re-scheduling as the profiling has shown that this is not a huge overhead after all.

[totaam]

Closing in favour of #3978