clipboard code should not compress in the UI thread, not assume zlib

[totaam]

Issue migrated from trac ticket # 621

component: core | priority: critical | resolution: fixed

2014-07-30 13:55:36: totaam created the issue

---

Difficulty is that the clipboard knows nothing about compression feature availability, as it is not directly tied to a client connection, at least on the server. When a new client comes in, we just hand over the clipboard instance...

Also, it does not have access to the per-client encoding thread, which would be the ideal place for slotting the compression work...

[totaam]

2014-07-30 15:27:31: totaam changed status from new to assigned

[totaam]

2014-07-30 15:27:31: totaam changed owner from antoine to totaam

[totaam]

2014-07-30 15:27:31: totaam commented

---

Groundwork done in r7041, we no longer assume zlib.

Remains:

• on the server: compress using the self.damage_data_queue (which should be renamed as compression queue or something more generic), or using a wrapper telling the network encode layer to do it
• on the client: we don't have any work queues, so it will probably have to be done by the network layer

[totaam]

2014-07-31 05:59:40: totaam changed status from assigned to closed

[totaam]

2014-07-31 05:59:40: totaam changed resolution from ** to fixed

[totaam]

2014-07-31 05:59:40: totaam commented

---

• server encodes from the 'encode' thread as of r7049 - which means that clipboard can no longer arrive before the screen updates that go with it
• client encodes from the 'format' network thread as of r7051

Some ugly code remains in compressed_wrapper calls, but that is now well isolated and can be dealt with later.