multi delta

Description

At the moment, we only use delta compression for non video screen updates using the last suitable region we had. Multiple updates of differing sizes means we will constantly change the delta buffer, and never match anything.

We could let the client tell the server how many buffers it will accept, and of what size.
Then the server can keep more delta regions in memory, keyed using their dimensions, and is more likely to make use of them.

This will help with things like unnecessary repaints (#670).
The only difficulty will be with UDP and dropped packets #639: we will need a way of requesting a reset / refresh when we are missing a reference region.

More improvements in r8315, r8311, r8309: we now re-stride the data, and directly into the target buffer in Cython, so now much faster.
I don't think we want to apply the delta-free patch above: too much complexity and extra code in the hot path, all for small memory savings. If we want to constrain the client memory usage, a better approach would be to let the client specify its own limit for the size of delta buffers. That's on top of being able to choose the number of delta buffers already via:

XPRA_DELTA_BUCKETS=10 xpra attach ..

Ready for testing, #760 may be helpful here to visualize where we use delta regions (and see if we miss any).

I would note that setting XPRA_DELTA_BUCKETS=11 does seem to lead to increased blurriness, even on a small window on a 1080p display.

It is not meant to.

I should explain: delta means that we substract the previous contents of a region from its current contents before compression.
So if you end up showing more or less the same contents, you end up with something empty as delta - which compresses very well.
Video compressors already do this by default (that's why they compress so well - and also why the size of the video cannot change without a full encoder re-initialization), we use delta compression on lossless picture encodings (rgb24/rgb32+lz4 and png) to benefit from the same trick.

Testing some more with 0.15.0 r8647 win32 client against 0.15.0 r8661 fedora 20 server... it looks like the blurriness when scrolling is resolving itself promptly (perhaps previous tests hit some extra latency... or maybe I was just using a monitor that periodically seems to actually be becoming blurry itself... not certain).

However... testing this I'm suddenly seeing that unicode error from #786 again (in this case 2015-02-20 17:31:10,731 unexpected data type <type 'unicode'> in logging packet: u'using audio codec: MPEG 1 Audio, Layer 3 (MP3)'), and I'm also seeing another message that I'm also seeing in a number of other places (not sure it's related specifically to this, thought it was a webkit browser related error until just now): 2015-02-20 17:25:13,779 failed to set group leader: 'module' object has no attribute 'SHGetPropertyStoreForWindow'.

In case it is liable to make matters clear, launched the server with the following:

Using firefox to test for delta processing, I'm periodically (mostly when opening a new tab, but not exactly correspondingly) seeing the failed to set group leader: 'module' object has no attribute 'SHGetPropertyStoreForWindow' error repeating.

Not sure if it is a combination of the global variable settings that is triggering these messages or if it is just a matter of my now aging test versions... any insights where to start (I mention here just before we close this delta ticket, because the combination of the global variables and the client debug forwarding seems to have triggered those messages which I was no longer seeing when testing #786 without all the other variables and log forwarding in place)... before I try going through the bits and pieces randomly until I find a combination-culprit?